Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

2018-02-18 Thread Kai-Heng Feng


> On 16 Feb 2018, at 8:10 PM, Hans de Goede  wrote:
> 
> 
> Ok, I've asked the reporter of:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1514836
> 
> Which is how I got involved in this to provide DMI data and
> I will whip up a patch for his machine and ask him to test
> and once that is done submit upstream. This is the only machine
> I'm aware of though and looking at the history of this I think
> there will be others.

I have one machine needs the quirk. I’ll also send a patch to
match its DMI.

Kai-Heng

> 
>> I addition we can add a module option to btusb.ko that allows us to force 
>> this flag to be set. That way testing this is easy on a vendor kernel. A 
>> bunch of the btusb quirks (and also core quirks) can be tested via module 
>> options or debugfs.
> 
> Yes a module option for this is a good idea.
> 
> Regards,
> 
> Hans
> 
> 



Use of GCC plugin instead ISO C

2018-02-18 Thread Progyan Bhattacharya
Hi Again,

According to last time talked, you said me to avoid "-Werror=pedantic"
flag to build the GNU specific plugins instead of Standard ISO C. I
changed my default compiler flags and tried to rebuild. But I am still
getting the same error messages at:

CC /***/Linux/tools/objtool/arch/x86/decode.o

All of them were arising due to same "-pedantic" flag being enabled.
1. Range expression in Case statements were not allowed.
2. Use of braced-group were not allowed in MACRO definition.
3. Pointer arithmetic with void pointer was not allowed.

I took a look on related Makefiles, but found none with "-pedantic" or
"-Werror=pedantic" flag.

Flags I found being used in compilation so far,

tools/objtool/Makefile:
-Wall -Werror -Wno-switch-default -Wno-switch-enum -Wno-packed
tools/scripts/Makefile.include:
-Wbad-function-cast -Wdeclaration-after-statement -Wformat-
security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-
prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition
-Wpacked -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-
default -Wswitch-enum -Wundef -Wwrite-strings -Wformat

Compiler I am using:
gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)

Thanks in advance.
-- 
Regards,
Progyan Bhattacharya
(http://codeprogyan.me)


[RESEND PATCH v2] checkpatch: add Crypto ON_STACK to declaration_macros

2018-02-18 Thread Gilad Ben-Yossef
Add the crypto API *_ON_STACK to $declaration_macros.

Resolves the following false warning:

WARNING: Missing a blank line after declarations
+   int err;
+   SHASH_DESC_ON_STACK(desc, ctx_p->shash_tfm);

Acked-by: Greg Kroah-Hartman 
Signed-off-by: Gilad Ben-Yossef 
---
 scripts/checkpatch.pl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3d40403..7d632645 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -791,7 +791,8 @@ our $FuncArg = 
qr{$Typecast{0,1}($LvalOrFunc|$Constant|$String)};
 our $declaration_macros = qr{(?x:

(?:$Storage\s+)?(?:[A-Z_][A-Z0-9]*_){0,2}(?:DEFINE|DECLARE)(?:_[A-Z0-9]+){1,6}\s*\(|
(?:$Storage\s+)?[HLP]?LIST_HEAD\s*\(|
-   (?:$Storage\s+)?${Type}\s+uninitialized_var\s*\(
+   (?:$Storage\s+)?${Type}\s+uninitialized_var\s*\(|
+   (?:SKCIPHER_REQUEST|SHASH_DESC|AHASH_REQUEST)_ON_STACK\s*\(
 )};
 
 sub deparenthesize {
-- 
2.7.4



linux-next: Signed-off-by missing for commit in the tip tree

2018-02-18 Thread Stephen Rothwell
Hi all,

Commit

  f091f1d6a2b4 ("tools/headers: Synchronize kernel ABI headers, v4.16-rc1")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


pgpcEKyb3pYjf.pgp
Description: OpenPGP digital signature


Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

2018-02-18 Thread Andy Shevchenko
On Fri, Feb 16, 2018 at 6:53 PM, Colin Ian King
 wrote:
> On 16/02/18 16:51, Andy Shevchenko wrote:
>> On Thu, Feb 15, 2018 at 9:42 PM, Colin King  wrote:

>>> +   filter->f.mask.tcp_spec.dst_ip[i] |=
>>> 
>>> cpu_to_be32(0x);
>>
>> Can it be one line then?
>
> I re-adjusted the text because checkpatch was complaining.

>>
>>> +   filter->f.mask.tcp_spec.src_ip[i] |=
>>> 
>>> cpu_to_be32(0x);

For the rest OK, but for the above two how much over 80 it went if
would be one line?
If it 2-3 characters, consider to make it one line. It would increase
readability.

-- 
With Best Regards,
Andy Shevchenko


Re: [PATCH] soc: actions: Convert to SPDX license identifiers

2018-02-18 Thread Andreas Färber
Am 21.01.2018 um 18:01 schrieb Andreas Färber:
> Replace textual license notices with SPDX-License-Identifier lines.
> Add an SPDX-License-Identifier for the Makefile.
> 
> Signed-off-by: Andreas Färber 
> ---
>  drivers/soc/actions/Makefile | 2 ++
>  drivers/soc/actions/owl-sps-helper.c | 6 +-
>  drivers/soc/actions/owl-sps.c| 6 +-
>  3 files changed, 4 insertions(+), 10 deletions(-)

Applied to v4.17/drivers:
https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-actions.git/log/?h=v4.17/drivers

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)


Seeking guidance on spelling fixes

2018-02-18 Thread David Frey
I noticed a common spelling mistake in some Linux kernel code that I was
reading the other day and it made me wonder how prevalent common spelling
mistakes are in the kernel.  I did some grepping and it seems that there
are a large number of spelling mistakes.  I did a bit of searching and I
found (http://www.kegel.com/kerspell/) which includes some comments/tools
relating to spelling and the Linux kernel.

I have gone ahead and corrected about 100 total instances based on 25
common misspellings.  There are many, many more common misspellings that I
could check, but I don't want to sink more time into this if the changes
won't be accepted.

Is this type of change likely to be accepted?  Right now I am making
individual git commits for each correction.  For example "aditional ->
additional".  I figured that it would be easier to review the list of
replacements rather than a mega-patch which fixes many different errors.
This way if any of the changes are controversial, I can easily rebase them
out.

I am trying to only correct true misspellings.  I'm not trying to choose
the "most correct" spelling for cases where there are acceptable alternate
spellings.

I've pushed the changes I have made so far to a "spelling_fixes" branch
here: https://github.com/dpfrey/linux/commits/spelling_fixes just in case
there is any question about what I am doing based on the above description.

Just to be clear, I'm not trying to get this portion of the work merged at
this point.  I'm trying to get a feel for whether I should keep working on
this.

Thanks,
David Frey




Re: [PATCH 1/2] kconfig: remove check_stdin()

2018-02-18 Thread Sam Ravnborg
On Thu, Feb 08, 2018 at 02:56:39PM +0900, Masahiro Yamada wrote:
> Except silentoldconfig, valid_stdin is 1, so check_stdin() is no-op.
> 
> oldconfig and silentoldconfig work almost in the same way except that
> the latter generates additional files.  Both ask users for input for
> new symbols.
> 
> I do not know why only silentoldconfig requires stdio be tty.

The general idea was to error out if stdout was not a tty and
kconfig wanted to prompt the user for anything.

So we avoided having a kconfig that would hang waiting for
user inputs when the user could not see that anything was prompted for.

The actual implementation may not follow this today as many seems not
to be aware of this little trick.

Sam


Re: [PATCH 6/7] platform/x86: fujitsu-laptop: Define constants for backlight power control

2018-02-18 Thread Michał Kępień
> > +/* FUNC interface - backlight power control */
> > +#define BACKLIGHT_POWER0x4
> > +#define BACKLIGHT_OFF  0x3
> > +#define BACKLIGHT_ON   0x0
> 
> A minor detail: BACKLIGHT_OFF and BACKLIGHT_ON are potential parameter
> values while BACKLIGHT_POWER is essentially a parameter selector.  Should
> the name of BACKLIGHT_POWER reflect this difference?  It could be difficult
> to do without making the resulting identifier a little long.  The best I can
> come up with is BACKLIGHT_PARAM_POWER or (if a saving of one character is
> desired) BACKLIGHT_PARM_POWER.

So, I tried to somehow unify constant naming throughout the module a few
times by now, but it seems that whichever naming pattern I chose, there
was always some exception to the rule.  Of course the module code is not
to blame, it is caused by the firmware treating logically related
features (like controlling various LEDs) in diverse ways.

Thus, I am perfectly fine with using BACKLIGHT_PARAM_POWER for now,
because I do not have a better idea yet.  If I ever come up with a
constant naming scheme that would cover all the constants in the module
(or at least all those directly related to call_fext_func()), I will
propose it here.

> > @@ -818,7 +825,8 @@ static int acpi_fujitsu_laptop_add(struct acpi_device 
> > *device)
> > /* Sync backlight power status */
> > if (fujitsu_bl && fujitsu_bl->bl_device &&
> > acpi_video_get_backlight_type() == acpi_backlight_vendor) {
> > -   if (call_fext_func(fext, FUNC_BACKLIGHT, 0x2, 0x4, 0x0) == 3)
> > +   if (call_fext_func(fext, FUNC_BACKLIGHT, 0x2, BACKLIGHT_POWER,
> > +  0x0) == 3)
> > fujitsu_bl->bl_device->props.power = FB_BLANK_POWERDOWN;
> > else
> > fujitsu_bl->bl_device->props.power = FB_BLANK_UNBLANK;
> 
> I'm curious: this fext function call is, I think, returning the current
> backlight power value.  If that's the case, is the value of 3 used in the
> test of the return function conceptually BACKLIGHT_OFF, and if so, should we
> use BACKLIGHT_OFF instead of the numeric constant?  It seems likely given
> that it results in the backlight power property being set to
> FB_BLANK_POWERDOWN.

Ah, yes, good catch.  Will fix, thanks.

-- 
Best regards,
Michał Kępień


[PATCH v2 2/2] staging: rtl8712: fix signedness of length to rtl8717_set_ie

2018-02-18 Thread Stefano Manni
rtl8717_set_it() takes an unsigned int pointer as length,
fixed signedness in code using it.

Sparse warnings:

drivers/staging/rtl8712/ieee80211.c:191:53: warning: incorrect type in argument 
5 (different signedness)
drivers/staging/rtl8712/ieee80211.c:191:53:expected unsigned int [usertype] 
*frlen
drivers/staging/rtl8712/ieee80211.c:191:53:got int *
drivers/staging/rtl8712/ieee80211.c:197:57: warning: incorrect type in argument 
5 (different signedness)
drivers/staging/rtl8712/ieee80211.c:197:57:expected unsigned int [usertype] 
*frlen
drivers/staging/rtl8712/ieee80211.c:197:57:got int *
drivers/staging/rtl8712/ieee80211.c:199:63: warning: incorrect type in argument 
5 (different signedness)
drivers/staging/rtl8712/ieee80211.c:199:63:expected unsigned int [usertype] 
*frlen
drivers/staging/rtl8712/ieee80211.c:199:63:got int *
drivers/staging/rtl8712/ieee80211.c:202:67: warning: incorrect type in argument 
5 (different signedness)
drivers/staging/rtl8712/ieee80211.c:202:67:expected unsigned int [usertype] 
*frlen
drivers/staging/rtl8712/ieee80211.c:202:67:got int *
drivers/staging/rtl8712/ieee80211.c:206:73: warning: incorrect type in argument 
5 (different signedness)
drivers/staging/rtl8712/ieee80211.c:206:73:expected unsigned int [usertype] 
*frlen
drivers/staging/rtl8712/ieee80211.c:206:73:got int *
drivers/staging/rtl8712/ieee80211.c:209:75: warning: incorrect type in argument 
5 (different signedness)
drivers/staging/rtl8712/ieee80211.c:209:75:expected unsigned int [usertype] 
*frlen
drivers/staging/rtl8712/ieee80211.c:209:75:got int *

Signed-off-by: Stefano Manni 
---
 drivers/staging/rtl8712/ieee80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/ieee80211.c 
b/drivers/staging/rtl8712/ieee80211.c
index 612ccfe..7a4c00e 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -166,7 +166,8 @@ static uint r8712_get_rateset_len(u8 *rateset)
 
 int r8712_generate_ie(struct registry_priv *pregistrypriv)
 {
-   int sz = 0, rate_len;
+   int rate_len;
+   uint sz = 0;
struct wlan_bssid_ex *pdev_network = >dev_network;
u8 *ie = pdev_network->IEs;
u16 beaconPeriod = (u16)pdev_network->Configuration.BeaconPeriod;
-- 
2.9.4



[PATCH v2 1/2] staging: rtl8712: make unsigned length for rtl8717_get{_wpa_,_wpa2_,_}ie

2018-02-18 Thread Stefano Manni
Fixed r8712_get_ie, r8712_get_wpa_ie, r8712_get_wpa2_ie
to have a length as unsigned int pointer instead of signed.

Sparse warnings:

drivers/staging/rtl8712/rtl871x_ioctl_linux.c:173:27: warning: incorrect type 
in argument 3 (different signedness)
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:173:27:expected signed int 
*len
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:173:27:got unsigned int 
*
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:613:35: warning: incorrect type 
in argument 3 (different signedness)
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:613:35:expected signed int 
*len
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:613:35:got unsigned int 
*
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1411:67: warning: incorrect type 
in argument 3 (different signedness)
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1411:67:expected signed int 
*len
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1411:67:got unsigned int 
*
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1992:33: warning: incorrect type 
in argument 2 (different signedness)
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1992:33:expected int 
*rsn_ie_len
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1992:33:got unsigned int 
*
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1998:33: warning: incorrect type 
in argument 2 (different signedness)
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1998:33:expected int 
*rsn_ie_len
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1998:33:got unsigned int 
*
drivers/staging/rtl8712/rtl871x_mlme.c:1701:59: warning: incorrect type in 
argument 3 (different signedness)
drivers/staging/rtl8712/rtl871x_mlme.c:1701:59:expected signed int *len
drivers/staging/rtl8712/rtl871x_mlme.c:1701:59:got unsigned int *

Signed-off-by: Stefano Manni 
---
 drivers/staging/rtl8712/ieee80211.c| 8 
 drivers/staging/rtl8712/ieee80211.h| 6 +++---
 drivers/staging/rtl8712/rtl871x_mlme.c | 3 ++-
 drivers/staging/rtl8712/rtl871x_xmit.c | 2 +-
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rtl8712/ieee80211.c 
b/drivers/staging/rtl8712/ieee80211.c
index 9872703..612ccfe 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -107,7 +107,7 @@ u8 *r8712_set_ie(u8 *pbuf, sint index, uint len, u8 
*source, uint *frlen)
  * index: the information element id index, limit is the limit for search
  * ---
  */
-u8 *r8712_get_ie(u8 *pbuf, sint index, sint *len, sint limit)
+u8 *r8712_get_ie(u8 *pbuf, sint index, uint *len, sint limit)
 {
sint tmp, i;
u8 *p;
@@ -211,9 +211,9 @@ int r8712_generate_ie(struct registry_priv *pregistrypriv)
return sz;
 }
 
-unsigned char *r8712_get_wpa_ie(unsigned char *pie, int *wpa_ie_len, int limit)
+unsigned char *r8712_get_wpa_ie(unsigned char *pie, uint *wpa_ie_len, int 
limit)
 {
-   int len;
+   u32 len;
u16 val16;
unsigned char wpa_oui_type[] = {0x00, 0x50, 0xf2, 0x01};
u8 *pbuf = pie;
@@ -245,7 +245,7 @@ unsigned char *r8712_get_wpa_ie(unsigned char *pie, int 
*wpa_ie_len, int limit)
return NULL;
 }
 
-unsigned char *r8712_get_wpa2_ie(unsigned char *pie, int *rsn_ie_len, int 
limit)
+unsigned char *r8712_get_wpa2_ie(unsigned char *pie, uint *rsn_ie_len, int 
limit)
 {
return r8712_get_ie(pie, _WPA2_IE_ID_, rsn_ie_len, limit);
 }
diff --git a/drivers/staging/rtl8712/ieee80211.h 
b/drivers/staging/rtl8712/ieee80211.h
index 68fd65e..d605dfd 100644
--- a/drivers/staging/rtl8712/ieee80211.h
+++ b/drivers/staging/rtl8712/ieee80211.h
@@ -738,9 +738,9 @@ static inline int ieee80211_get_hdrlen(u16 fc)
 struct registry_priv;
 
 u8 *r8712_set_ie(u8 *pbuf, sint index, uint len, u8 *source, uint *frlen);
-u8 *r8712_get_ie(u8 *pbuf, sint index, sint *len, sint limit);
-unsigned char *r8712_get_wpa_ie(unsigned char *pie, int *rsn_ie_len, int 
limit);
-unsigned char *r8712_get_wpa2_ie(unsigned char *pie, int *rsn_ie_len,
+u8 *r8712_get_ie(u8 *pbuf, sint index, uint *len, sint limit);
+unsigned char *r8712_get_wpa_ie(unsigned char *pie, uint *rsn_ie_len, int 
limit);
+unsigned char *r8712_get_wpa2_ie(unsigned char *pie, uint *rsn_ie_len,
 int limit);
 int r8712_parse_wpa_ie(u8 *wpa_ie, int wpa_ie_len, int *group_cipher,
   int *pairwise_cipher);
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c 
b/drivers/staging/rtl8712/rtl871x_mlme.c
index 7824508..ac547dd 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -1725,7 +1725,8 @@ unsigned int r8712_restructure_ht_ie(struct _adapter 
*padapter, u8 *in_ie,
 static void update_ht_cap(struct _adapter *padapter, u8 *pie, uint ie_len)
 {
u8 *p, max_ampdu_sz;
-   int i, len;
+   int i;
+   uint len;
struct sta_info *bmc_sta, *psta;
struct 

Re: [PATCH 1/2] staging: rtl8712: make unsigned length for rtl8717_get{_wpa_,_wpa2_,_}ie

2018-02-18 Thread Stefano Manni
On Fri, 2018-02-16 at 15:48 +0100, Greg KH wrote:
> Can you rebase both of these patches on the staging-testing branch of
> the staging.git tree so that I can apply them?  Right now they have
> too
> many conflicts.

Rebased on staging-testing d92a1fa. v2 to come.




linux-next: Signed-off-by missing for commit in the parisc-hd tree

2018-02-18 Thread Stephen Rothwell
Hi all,

Commit

  6c2dfd2e720d ("parisc: Fix ordering of cache and TLB flushes")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


pgpKR_OlCUktq.pgp
Description: OpenPGP digital signature


[no subject]

2018-02-18 Thread Alfred Cheuk Yu Chow


Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, Chong Hing Bank Center, 24 Des Voeux Road Central,
Hong Kong. I have a business proposal of $ 38,980,369.00.

All confirmable documents to back up the claims will be made available
to you prior to your acceptance and as soon as I receive your return
mail.

Best Regards,
Alfred Chow.








[no subject]

2018-02-18 Thread Alfred Chow




Good Day,

This is the second time i am sending you this mail.

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, need your alliance in a deal that will be of  
mutual benefit.


Email me back for more details.

Regards.







Re: [PATCH v3 01/25] dt-bindings: soc: qcom: Add bindings for APR bus

2018-02-18 Thread Rob Herring
On Wed, Feb 14, 2018 at 09:13:23AM +, Srinivas Kandagatla wrote:
> Thanks for the review,
> 
> On 13/02/18 23:12, Rob Herring wrote:
> > On Tue, Feb 13, 2018 at 04:58:13PM +, srinivas.kandaga...@linaro.org 
> > wrote:
> > > From: Srinivas Kandagatla 
> > > 
> > > This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router)
> > > bus driver. This bus is used for communicating with DSP which provides
> > > audio and various other services to cpu.
> > > 
> > > Signed-off-by: Srinivas Kandagatla 
> > > ---
> > >   .../devicetree/bindings/soc/qcom/qcom,apr.txt  | 83 
> > > ++
> > >   1 file changed, 83 insertions(+)
> > >   create mode 100644 
> > > Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt 
> > > b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> > > new file mode 100644
> > > index ..1b95fbfed348
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> > > @@ -0,0 +1,83 @@
> > > +Qualcomm APR (Asynchronous Packet Router) binding
> > > +
> > > +This binding describes the Qualcomm APR. APR is a IPC protocol for
> > > +communication between Application processor and QDSP. APR is mainly
> > > +used for audio/voice services on the QDSP.
> > > +
> > > +- compatible:
> > > + Usage: required
> > > + Value type: 
> > > + Definition: must be "qcom,apr-v", example "qcom,apr-v2"
> > > +
> > > +- qcom,apr-dest-domain-id
> > > + Usage: required
> > > + Value type: 
> > > + Definition: Destination processor ID.
> > > + Possible values are :
> > > + 1 - APR simulator
> > > + 2 - PC
> > > + 3 - MODEM
> > > + 4 - ADSP
> > > + 5 - APPS
> > > + 6 - MODEM2
> > > + 7 - APPS2
> > > +
> > > += APR SERVICES
> > > +Each subnode of the APR node can represent service tied to this apr. The 
> > > name
> > > +of the nodes are not important. The properties of these nodes are defined
> > > +by the individual bindings for the specific service
> > > +- but must contain the following property:
> > > +
> ...
> > > += APR DEVICES:
> > > +Each subnode of the APR node can represent devices tied to this apr, like
> > > +sound-card. The properties of these nodes are defined by the individual
> > > +bindings for the specific device.
> > 
> > It's not a good design generally to mix different types of nodes at one
> > level.
> 
> I agree, may be I can split the services and devices into different subnodes
> like below, which should avoid mixing different types of nodes.
> 
> Does this sound good to you?

Seems your original example wasn't so complete...

I don't see why you need all these nodes in the first place. For a 
single SoC, how much does all this vary?

> 
> apr {
> compatible = "qcom,apr-v2";
> qcom,smd-channels = "apr_audio_svc";
> qcom,apr-dest-domain-id = ;
> 
> apr-services {
> q6core {
> qcom,apr-svc-name = "CORE";
> qcom,apr-svc-id = ;
> compatible = "qcom,q6core";
> };
> 
> q6afe: q6afe {
> compatible = "qcom,q6afe";
> qcom,apr-svc-name = "AFE";
> qcom,apr-svc-id = ;
> #sound-dai-cells = <1>;
> };
> 
> q6asm: q6asm {
> compatible = "qcom,q6asm";
> qcom,apr-svc-name = "ASM";
> qcom,apr-svc-id = ;
> #sound-dai-cells = <1>;
> };
> 
> q6adm: q6adm {
> compatible = "qcom,q6adm";
> qcom,apr-svc-name = "ADM";
> qcom,apr-svc-id = ;
> #sound-dai-cells = <0>;
> };

All these DAI nodes could be a single node and the cell value be the 
svc-id?

> };
> 
> apr-devices {
> audio {
> compatible = "qcom,msm8996-snd-card";

This is a pseudo device. Why not put it at the top level like other 
sound cards?

> ...
> };
> };
> };
> 
> 
> 
> 
> > 
> > > +
> > > += EXAMPLE
> > > +The following example represents a QDSP based sound card on a MSM8996 
> > > device
> > > +which uses apr as communication between Apps and QDSP.
> > > +
> > > + apr {
> > > + compatible = "qcom,apr-v2";
> > > + qcom,smd-channels = "apr_audio_svc";
> > > + qcom,apr-dest-domain-id = ;
> > > +
> > > + q6core {
> > > + compatible = "qcom,q6core";
> > > + qcom,apr-svc-name = "CORE";
> > > + qcom,apr-svc-id = ;
> > > + };
> > 

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

2018-02-18 Thread Stephen Rothwell
Hi all,

After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

In file included from include/linux/list.h:9:0,
 from include/linux/wait.h:7,
 from include/linux/wait_bit.h:8,
 from include/linux/fs.h:6,
 from include/linux/highmem.h:5,
 from drivers/gpu/drm/drm_memory.c:36:
drivers/gpu/drm/drm_memory.c: In function 'drm_get_max_iomem':
include/linux/kernel.h:808:16: warning: comparison of distinct pointer types 
lacks a cast
  (void) ( == );   \
^
include/linux/kernel.h:817:2: note: in expansion of macro '__max'
  __max(typeof(x), typeof(y),   \
  ^
drivers/gpu/drm/drm_memory.c:159:15: note: in expansion of macro 'max'
   max_iomem = max(max_iomem,  tmp->end);
   ^~~

Introduced by commit

  82626363a217 ("drm: add func to get max iomem address v2")

tmp->end is a resource_size_t ...

-- 
Cheers,
Stephen Rothwell


pgpv3mCOtSJYA.pgp
Description: OpenPGP digital signature


Re: [PATCH] srcu: Fix incorrect condition in srcu_funnel_exp_start()

2018-02-18 Thread Byungchul Park

On 2/15/2018 6:42 AM, Paul E. McKenney wrote:

On Wed, Feb 14, 2018 at 05:59:54PM +0900, Byungchul Park wrote:

We should've kept sp->srcu_gp_seq_needed_exp the furthest. But
it probably fails because of the incorrect condition. Fix it.

Signed-off-by: Byungchul Park 


Good catch, and thank you for reviewing the SRCU code, but Ildar Ismagilov
beat you to this one.  Please see 574428dee1f3 ("rcu: Fix misprint in
srcu_funnel_exp_start") in -rcu.


Hi Paul,

I'm sorry I'm late. It's been Lunar New Year holiday since last
thursday.

Do you mean:

git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git

Is this rcu's main dev-tree?

Thanks for replying anyway, and happy new year~



Thanx, Paul


---
  kernel/rcu/srcutree.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index d5cea81..44bc0fa 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -626,7 +626,7 @@ static void srcu_funnel_exp_start(struct srcu_struct *sp, 
struct srcu_node *snp,
spin_unlock_irqrestore_rcu_node(snp, flags);
}
spin_lock_irqsave_rcu_node(sp, flags);
-   if (!ULONG_CMP_LT(sp->srcu_gp_seq_needed_exp, s))
+   if (ULONG_CMP_LT(sp->srcu_gp_seq_needed_exp, s))
sp->srcu_gp_seq_needed_exp = s;
spin_unlock_irqrestore_rcu_node(sp, flags);
  }
--
1.9.1






--
Thanks,
Byungchul


Re: [PATCH v2 1/9] lib/test_printf: Mark big constant with ULL

2018-02-18 Thread Andy Shevchenko
On Sun, Feb 18, 2018 at 11:52 PM, Tobin C. Harding  wrote:
> On Fri, Feb 16, 2018 at 11:07:03PM +0200, Andy Shevchenko wrote:

> What tree does this set apply to please?  I tried mainline rc1 and
> next-20180216.  Happy to see some code duplication removal from
> vsprintf.c :)

IIRC latest next, i.e. 20180217.


-- 
With Best Regards,
Andy Shevchenko


Re: [PATCH 1/4] dt/bindings: fix binding examples for tegra gmi controller

2018-02-18 Thread Rob Herring
On Sat, Feb 10, 2018 at 02:33:22AM +0100, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Fix devicetree binding examples for the Generic Memory Interface (GMI)
> bus driver found on Tegra SOCs.
> 
> While at it also remove double new lines as a left over from Rob's
> commit 4da722ca19f3 ("dt-bindings: Remove "status" from examples").
> 
> Signed-off-by: Marcel Ziswiler 
> ---
> 
>  Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Reviewed-by: Rob Herring 



Re: [PATCH v3 3/7] watchdog: sirfsoc: allow setting timeout in devicetree

2018-02-18 Thread Guenter Roeck

On 02/18/2018 04:07 PM, Rob Herring wrote:

On Sun, Feb 11, 2018 at 09:08:43PM +0100, Marcus Folkesson wrote:

watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.

By following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt, it also
let us to set timout-sec property in devicetree.


typo



Signed-off-by: Marcus Folkesson 
Reviewed-by: Guenter Roeck 
---
  Documentation/devicetree/bindings/watchdog/sirfsoc_wdt.txt | 4 
  drivers/watchdog/sirfsoc_wdt.c | 2 +-
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/watchdog/sirfsoc_wdt.txt 
b/Documentation/devicetree/bindings/watchdog/sirfsoc_wdt.txt
index 9cbc76c89b2b..0dce5e3100b4 100644
--- a/Documentation/devicetree/bindings/watchdog/sirfsoc_wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/sirfsoc_wdt.txt
@@ -5,10 +5,14 @@ Required properties:
  - reg: Address range of tick timer/WDT register set
  - interrupts: interrupt number to the cpu
  
+Optional properties:

+- timeout-sec : Contains the watchdog timeout in seconds
+
  Example:
  
  timer@b002 {

compatible = "sirf,prima2-tick";
reg = <0xb002 0x1000>;
interrupts = <0>;
+   timeout-sec = <30>;
  };
diff --git a/drivers/watchdog/sirfsoc_wdt.c b/drivers/watchdog/sirfsoc_wdt.c
index 4eea351e09b0..ac0c9d2c4aee 100644
--- a/drivers/watchdog/sirfsoc_wdt.c
+++ b/drivers/watchdog/sirfsoc_wdt.c
@@ -29,7 +29,7 @@
  #define SIRFSOC_WDT_MAX_TIMEOUT   (10 * 60)   /* 10 mins */
  #define SIRFSOC_WDT_DEFAULT_TIMEOUT   30  /* 30 secs */
  
-static unsigned int timeout = SIRFSOC_WDT_DEFAULT_TIMEOUT;

+static unsigned int timeout;


If you have an old dtb, then you still need the default.



No. It is optional to start with, and the driver already has

static struct watchdog_device sirfsoc_wdd = {
.info = _wdt_ident,
.ops = _wdt_ops,
.timeout = SIRFSOC_WDT_DEFAULT_TIMEOUT, <--
.min_timeout = SIRFSOC_WDT_MIN_TIMEOUT,
.max_timeout = SIRFSOC_WDT_MAX_TIMEOUT,
};

Guenter


  static bool nowayout = WATCHDOG_NOWAYOUT;
  
  module_param(timeout, uint, 0);

--
2.15.1







Re: [PATCH] kbuild: Don't source kernel config

2018-02-18 Thread kbuild test robot
Hi Richard,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc1 next-20180216]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Richard-Weinberger/kbuild-Don-t-source-kernel-config/20180219-082820
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> scripts/link-vmlinux.sh: line 229: scripts/importkconf.sh: No such file or 
>> directory

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


.config.gz
Description: application/gzip


Re: [PATCH v2] serial: 8250: Add Nuvoton NPCM UART

2018-02-18 Thread Rob Herring
On Thu, Feb 15, 2018 at 12:47:20PM +1030, Joel Stanley wrote:
> The Nuvoton UART is almost compatible with the 8250 driver when probed
> via the 8250_of driver, however it requires some extra configuration
> at startup.
> 
> Signed-off-by: Joel Stanley 
> ---
> v2:
>  Remove redundant whitespace
>  Use port number 40 to fill in a gap
> 
>  Documentation/devicetree/bindings/serial/8250.txt |  1 +

Reviewed-by: Rob Herring 

>  drivers/tty/serial/8250/8250_of.c |  1 +
>  drivers/tty/serial/8250/8250_port.c   | 29 
> +++
>  include/uapi/linux/serial_core.h  |  3 +++
>  include/uapi/linux/serial_reg.h   |  5 
>  5 files changed, 39 insertions(+)


Re: [PATCH] kbuild: Don't source kernel config

2018-02-18 Thread kbuild test robot
Hi Richard,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180216]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Richard-Weinberger/kbuild-Don-t-source-kernel-config/20180219-082820
config: mips-64r6el_defconfig (attached as .config)
compiler: mips64el-linux-gnuabi64-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> scripts/adjust_autoksyms.sh: line 42: scripts/importkconf.sh: No such file 
>> or directory

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


.config.gz
Description: application/gzip


Re: [PATCH 1/1] scsi: ufs: Add support for Auto-Hibernate Idle Timer

2018-02-18 Thread Adrian Hunter
On 18/02/18 11:45, Avri Altman wrote:
> 
> 
>> -Original Message-
>> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>> ow...@vger.kernel.org] On Behalf Of Adrian Hunter
>> Sent: Friday, February 16, 2018 2:01 PM
>> To: Vinayak Holikatti ; Martin K. Petersen
>> ; James E.J. Bottomley
>> 
>> Cc: Stanislav Nijnikov ; Jaegeuk Kim
>> ; Bart Van Assche ; linux-
>> s...@vger.kernel.org; linux-kernel@vger.kernel.org; Michal Potomski
>> ; Szymon Mielczarek
>> 
>> Subject: [PATCH 1/1] scsi: ufs: Add support for Auto-Hibernate Idle Timer
>>
>> UFS host controllers may support an autonomous power management
>> feature called the Auto-Hibernate Idle Timer. The timer is set to the number
>> of microseconds of idle time before the UFS host controller will
>> autonomously put the link into Hibernate state. That will save power at the
>> expense of increased latency. Any access to the host controller interface
>> registers will automatically put the link out of Hibernate state. So once
>> configured, the feature is transparent to the driver.
>>
>> Expose the Auto-Hibernate Idle Timer value via SysFS to allow users to
>> choose between power efficiency or lower latency. Set a default value of
>> 150 ms.
>>
>> Signed-off-by: Adrian Hunter 
>> ---
>>  Documentation/ABI/testing/sysfs-driver-ufs | 15 ++
>>  drivers/scsi/ufs/ufs-sysfs.c   | 77 
>> ++
>>  drivers/scsi/ufs/ufshcd.c  | 26 ++
>>  drivers/scsi/ufs/ufshcd.h  |  3 ++
>>  drivers/scsi/ufs/ufshci.h  |  7 +++
>>  5 files changed, 128 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-driver-ufs
>> b/Documentation/ABI/testing/sysfs-driver-ufs
>> index 07f1c2f8dbfc..c7f9441079eb 100644
>> --- a/Documentation/ABI/testing/sysfs-driver-ufs
>> +++ b/Documentation/ABI/testing/sysfs-driver-ufs
>> @@ -1,3 +1,18 @@
>> +What:   /sys/bus/*/drivers/ufshcd/*/auto_hibern8
>> +Date:   February 2018
>> +Contact:linux-s...@vger.kernel.org
>> +Description:
>> +This file contains the auto-hibernate idle timer setting of a
>> +UFS host controller. A value of '-1' means auto-hibernate is
>> not
>> +supported. A value of '0' means auto-hibernate is not
>> enabled.
>> +Otherwise the value is the number of microseconds of idle
>> time
>> +before the UFS host controller will autonomously put the link
>> +into hibernate state. That will save power at the expense of
>> +increased latency. Note that the hardware supports 10-bit
>> values
>> +with a power-of-ten multiplier which allows a maximum
>> value of
>> +10230. Refer to the UFS Host Controller Interface
>> +specification for more details.
>> +
>>  What:
>>  /sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_type
>>  Date:   February 2018
>>  Contact:Stanislav Nijnikov 
>> diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c 
>> index
>> cd7174d2d225..a0e38776dc92 100644
>> --- a/drivers/scsi/ufs/ufs-sysfs.c
>> +++ b/drivers/scsi/ufs/ufs-sysfs.c
>> @@ -3,6 +3,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include "ufs.h"
>> @@ -123,12 +124,88 @@ static ssize_t spm_lvl_store(struct device *dev,
>>  return ufs_sysfs_pm_lvl_store(dev, attr, buf, count, false);  }
>>
>> +static void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit) {
>> +unsigned long flags;
>> +
>> +if (!(hba->capabilities & MASK_AUTO_HIBERN8_SUPPORT))
>> +return;
>> +
>> +spin_lock_irqsave(hba->host->host_lock, flags);
>> +if (hba->ahit == ahit)
>> +goto out_unlock;
>> +hba->ahit = ahit;
>> +if (!pm_runtime_suspended(hba->dev))
>> +ufshcd_writel(hba, hba->ahit,
>> REG_AUTO_HIBERNATE_IDLE_TIMER);
>> +out_unlock:
>> +spin_unlock_irqrestore(hba->host->host_lock, flags); }
>> +
>> +/* Convert Auto-Hibernate Idle Timer register value to microseconds */
>> +static int ufshcd_ahit_to_us(u32 ahit) {
>> +int timer = FIELD_GET(UFSHCI_AHIBERN8_TIMER_MASK, ahit);
>> +int scale = FIELD_GET(UFSHCI_AHIBERN8_SCALE_MASK, ahit);
>> +
>> +for (; scale > 0; --scale)
>> +timer *= UFSHCI_AHIBERN8_SCALE_FACTOR;
>> +
>> +return timer;
>> +}
>> +
>> +/* Convert microseconds to Auto-Hibernate Idle Timer register value */
>> +static u32 ufshcd_us_to_ahit(unsigned int timer) {
>> +unsigned int scale;
>> +
>> +for (scale = 0; timer > UFSHCI_AHIBERN8_TIMER_MASK; ++scale)
>> +timer /= UFSHCI_AHIBERN8_SCALE_FACTOR;
>> +
>> +return FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, timer) |

Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")

2018-02-18 Thread Hannes Reinecke
On 02/18/2018 07:33 PM, Max Ivanov wrote:
> Hi,
> 
> on my system I can't logout from iSCSI session when on 4.4.18, but
> 4.3.19 works just fine. git bisect points to  fbce4d97fd ("scsi: fixup
> kernel warning during rmmod()")
> 
> Bug manifests itself like following:
>   - iSCSI session logout hangs and never completes
>   - 1 kworker per iSCSI session start consuming 100% CPU
>   - very shortly one of 2 errors show up in dmesg (full listings are below):
>   * kernel: list_del corruption, 88c1cd6bb810->next is LIST_POISON1
>   * kernel BUG at mm/slub.c:295!
> 
> Ways to trigger bug:
>   1. initiate iSCSI sessions to multiple portals
>   2. let multipathd to create multipath devices
>   3. run 'iscsiadm -m node --logoutall=all'
> 
> Bugs is NOT triggered and iSCSI logout succeeds when either:
>   - multipathd is masked and never started
>   - I manually delete all scsi devices via /sys/block/$d/device/delete
> before attempting
> to do iSCSI logout
> 
> list_del_corrpution:
> 
> Feb 16 10:37:11 localhost.localdomain kernel: alua: device handler registered
> Feb 16 10:37:11 localhost.localdomain kernel: emc: device handler registered
> Feb 16 10:37:11 localhost.localdomain kernel: rdac: device handler registered
> Feb 16 10:37:11 localhost.localdomain kernel: device-mapper: multipath
> service-time: version 0.3.0 loaded
> Feb 16 10:38:38 localhost.localdomain kernel: list_del corruption,
> 88c1cd6bb810->next is LIST_POISON1 (dead0100)
> Feb 16 10:38:38 localhost.localdomain kernel: [ cut here
> ]
> Feb 16 10:38:38 localhost.localdomain kernel: kernel BUG at 
> lib/list_debug.c:47!
> Feb 16 10:38:38 localhost.localdomain kernel: invalid opcode:  [#1] SMP 
> PTI
> Feb 16 10:38:38 localhost.localdomain kernel: Modules linked in:
> dm_service_time dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua
> binfmt_misc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink
> ebtable_nat ebtable_broute bridge stp llc ip6tabl
> Feb 16 10:38:38 localhost.localdomain kernel:  pata_acpi
> Feb 16 10:38:38 localhost.localdomain kernel: CPU: 2 PID: 5 Comm:
> kworker/u24:0 Not tainted 4.14.18-300.fc27.x86_64 #1
> Feb 16 10:38:38 localhost.localdomain kernel: Hardware name: VMware,
> Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS
> 6.00 09/21/2015
> Feb 16 10:38:38 localhost.localdomain kernel: Workqueue: scsi_wq_5
> __iscsi_unbind_session [scsi_transport_iscsi]
> Feb 16 10:38:38 localhost.localdomain kernel: task: 88bdede83e80
> task.stack: b15043158000
> Feb 16 10:38:38 localhost.localdomain kernel: RIP:
> 0010:__list_del_entry_valid+0x4e/0x90
> Feb 16 10:38:38 localhost.localdomain kernel: RSP:
> 0018:b1504315bd88 EFLAGS: 00010082
> Feb 16 10:38:38 localhost.localdomain kernel: RAX: 004e
> RBX: 88c1cd6bbf38 RCX: 
> Feb 16 10:38:38 localhost.localdomain kernel: RDX: 
> RSI: 88bdefc96a38 RDI: 88bdefc96a38
> Feb 16 10:38:38 localhost.localdomain kernel: RBP: 0246
> R08: 07be R09: 00aa
> Feb 16 10:38:38 localhost.localdomain kernel: R10: b1504315bd58
> R11:  R12: 88c1ebb659c0
> Feb 16 10:38:38 localhost.localdomain kernel: R13: 88bdec827010
> R14: 88c1cd6bb800 R15: 88c1cd6bb800
> Feb 16 10:38:38 localhost.localdomain kernel: FS:
> () GS:88bdefc8()
> knlGS:
> Feb 16 10:38:38 localhost.localdomain kernel: CS:  0010 DS:  ES:
>  CR0: 80050033
> Feb 16 10:38:38 localhost.localdomain kernel: CR2: 563d0c1ed280
> CR3: 00057120a001 CR4: 001606e0
> Feb 16 10:38:38 localhost.localdomain kernel: Call Trace:
> Feb 16 10:38:38 localhost.localdomain kernel:
> scsi_device_dev_release_usercontext+0x52/0x250
> Feb 16 10:38:38 localhost.localdomain kernel:  ? __schedule+0x10f/0x880
> Feb 16 10:38:38 localhost.localdomain kernel:
> execute_in_process_context+0x21/0x60
> Feb 16 10:38:38 localhost.localdomain kernel:  device_release+0x30/0x80
> Feb 16 10:38:38 localhost.localdomain kernel:  kobject_put+0x80/0x1a0
> Feb 16 10:38:38 localhost.localdomain kernel:  scsi_remove_target+0x16d/0x1b0
> Feb 16 10:38:38 localhost.localdomain kernel:
> __iscsi_unbind_session+0xad/0x150 [scsi_transport_iscsi]
> Feb 16 10:38:38 localhost.localdomain kernel:  process_one_work+0x184/0x3a0
> Feb 16 10:38:38 localhost.localdomain kernel:  worker_thread+0x2e/0x380
> Feb 16 10:38:38 localhost.localdomain kernel:  ? process_one_work+0x3a0/0x3a0
> Feb 16 10:38:38 localhost.localdomain kernel:  kthread+0x11a/0x130
> Feb 16 10:38:38 localhost.localdomain kernel:  ? kthread_park+0x60/0x60
> Feb 16 10:38:38 localhost.localdomain kernel:  ret_from_fork+0x35/0x40
> Feb 16 10:38:38 localhost.localdomain kernel: Code: 74 2b 48 8b 32 48
> 39 fe 75 34 48 8b 50 08 48 39 f2 75 3f b8 01 00 00 00 c3 48 89 fe 48
> 89 c2 48 c7 

[PATCH 3/3] reset: simple: Allow user selection of driver

2018-02-18 Thread Joel Stanley
Currently this driver is only user selectable if COMPILE_TEST is turned
on. Users may wish to select (and deselect) it, so remove this
restriction.

Signed-off-by: Joel Stanley 
---
 drivers/reset/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 18f152d251d7..7490a4370900 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -82,7 +82,7 @@ config RESET_PISTACHIO
  This enables the reset driver for ImgTec Pistachio SoCs.
 
 config RESET_SIMPLE
-   bool "Simple Reset Controller Driver" if COMPILE_TEST
+   bool "Simple Reset Controller Driver"
default ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || 
ARCH_ZX || ARCH_ASPEED
help
  This enables a simple reset controller driver for reset lines that
-- 
2.15.1



[PATCH 2/3] reset: simple: Enable for ASPEED systems

2018-02-18 Thread Joel Stanley
ASPEED BMC SoCs have a reset controller in the LPC IP that can be
controlled using this driver to release the UARTs from reset.

No special configuration is required, so only the compatible string is
added.

Signed-off-by: Joel Stanley 
---
 drivers/reset/Kconfig| 10 +++---
 drivers/reset/reset-simple.c |  2 ++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 7fc77696bb1e..18f152d251d7 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -83,14 +83,18 @@ config RESET_PISTACHIO
 
 config RESET_SIMPLE
bool "Simple Reset Controller Driver" if COMPILE_TEST
-   default ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || 
ARCH_ZX
+   default ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || 
ARCH_ZX || ARCH_ASPEED
help
  This enables a simple reset controller driver for reset lines that
  that can be asserted and deasserted by toggling bits in a contiguous,
  exclusive register space.
 
- Currently this driver supports Altera SoCFPGAs, the RCC reset
- controller in STM32 MCUs, Allwinner SoCs, and ZTE's zx2967 family.
+ Currently this driver supports:
+  - Altera SoCFPGAs
+  - ASPEED BMC SoCs
+  - RCC reset controller in STM32 MCUs
+  - Allwinner SoCs
+  - ZTE's zx2967 family
 
 config RESET_SUNXI
bool "Allwinner SoCs Reset Driver" if COMPILE_TEST && !ARCH_SUNXI
diff --git a/drivers/reset/reset-simple.c b/drivers/reset/reset-simple.c
index 2d4f362ef025..f7ce8910a392 100644
--- a/drivers/reset/reset-simple.c
+++ b/drivers/reset/reset-simple.c
@@ -125,6 +125,8 @@ static const struct of_device_id reset_simple_dt_ids[] = {
.data = _simple_active_low },
{ .compatible = "zte,zx296718-reset",
.data = _simple_active_low },
+   { .compatible = "aspeed,ast2400-lpc-reset" },
+   { .compatible = "aspeed,ast2500-lpc-reset" },
{ /* sentinel */ },
 };
 
-- 
2.15.1



[PATCH] scsi: cxlflash: Select SCSI_SCAN_ASYNC

2018-02-18 Thread Vaibhav Jain
The cxlflash driver uses "Asynchronous SCSI scanning" enabled by
CONFIG_SCSI_SCAN_ASYNC. Without this enabled the modprobe of cxlflash
module gets hung with following backtrace:

Call Trace:
 __switch_to+0x2cc/0x470
 __schedule+0x288/0xab0
 schedule+0x40/0xc0
 schedule_timeout+0x254/0x4f0
 wait_for_common+0xdc/0x260
 flush_work+0x140/0x2a0
 work_on_cpu+0x88/0xb0
 pci_device_probe+0x1d0/0x220
 driver_probe_device+0x408/0x5b0
 __driver_attach+0x16c/0x1a0
 bus_for_each_dev+0xb8/0x110
 driver_attach+0x3c/0x60
 bus_add_driver+0x1d8/0x370
 driver_register+0x9c/0x180
 __pci_register_driver+0x74/0xa0
 init_cxlflash+0x158/0x1cc
 do_one_initcall+0x68/0x1e0
 do_init_module+0x90/0x254
 load_module+0x2f8c/0x3720
 SyS_finit_module+0xcc/0x140
 system_call+0x58/0x6c

Signed-off-by: Vaibhav Jain 
---
 drivers/scsi/cxlflash/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/cxlflash/Kconfig b/drivers/scsi/cxlflash/Kconfig
index a011c5dbf214..f054c1b0fff3 100644
--- a/drivers/scsi/cxlflash/Kconfig
+++ b/drivers/scsi/cxlflash/Kconfig
@@ -6,6 +6,7 @@ config CXLFLASH
tristate "Support for IBM CAPI Flash"
depends on PCI && SCSI && CXL && EEH
select IRQ_POLL
+   select SCSI_SCAN_ASYNC
default m
help
  Allows CAPI Accelerated IO to Flash
-- 
2.14.3



Re: INFO: rcu detected stall in xfrm_confirm_neigh

2018-02-18 Thread Steffen Klassert
On Tue, Feb 13, 2018 at 10:19:17AM +0100, Dmitry Vyukov wrote:
> On Mon, Feb 12, 2018 at 4:26 PM, Dmitry Vyukov  wrote:
> > On Mon, Feb 12, 2018 at 4:23 PM, syzbot
> >  wrote:
> >> Hello,
> >>
> >> syzbot hit the following crash on net-next commit
> >> 9515a2e082f91457db0ecff4b65371d0fb5d9aad (Thu Jan 25 03:37:38 2018 +)
> >> net/ipv4: Allow send to local broadcast from a socket bound to a VRF
> >>
> >> So far this crash happened 6 times on net-next.
> >> Unfortunately, I don't have any reproducer for this crash yet.
> >> Raw console output is attached.
> >> compiler: gcc (GCC) 7.1.1 20170620
> >> .config is attached.
> >
> >
> > +xfrm maintainers
> 
> Here is a C repro:
> https://gist.githubusercontent.com/dvyukov/92c67ba9afaaa960bcfbdc6ef549ac10/raw/786f9221c1d707c7f4a15effcb1d5997dd4f8638/gistfile1.txt

Seems like syzbot does not know about this reproducer.

I've send a patch to test and got this as the reply:

This crash does not have a reproducer. I cannot test it.


Re: [PATCH] of: Kconfig: OF_OVERLAY, select OF_EARLY_FLATTREE

2018-02-18 Thread Frank Rowand
On 02/18/18 17:46, Rob Herring wrote:
> On Sun, Feb 18, 2018 at 6:29 PM,   wrote:
>> From: Frank Rowand 
>>
>> kbuild test robot reported a new warning for a recent patch:
 drivers/of/overlay.c:832:2: error: implicit declaration of function 
 'of_fdt_unflatten_tree' [-Werror=implicit-function-declaration]
>>  of_fdt_unflatten_tree(new_fdt, NULL, _root);
>>
>> The cause is that the prototype for of_fdt_unflatten_tree() in
>> include/linux/of_fdt.c is guarded by OF_EARLY_FLATTREE.
>>
>> This was a pre-existing problem for any overlay related caller of
>> of_fdt_unflatten_device_tree(), who was then going to pass the
>> unflattened tree to of_overlay_apply().  After the patch that triggered
>> this warning, all other overlay callers of of_fdt_unflatten_device_tree()
>> no longer exist, so adding the select to OF_OVERLAY is a sufficient fix.
>>
>> To reproduce the warning:
>>   Use the .config attached to https://lkml.org/lkml/2018/2/17/268
>>   make ARCH=i386 olddefconfig
>>   make ARCH=i386 CC=gcc-7 drivers/of/overlay.o
>>
>> Signed-off-by: Frank Rowand 
>> ---
>>  drivers/of/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>> index 783e0870bd22..00a6abfaaec7 100644
>> --- a/drivers/of/Kconfig
>> +++ b/drivers/of/Kconfig
>> @@ -92,6 +92,7 @@ config OF_RESOLVE
>>  config OF_OVERLAY
>> bool "Device Tree overlays"
>> select OF_DYNAMIC
>> +   select OF_EARLY_FLATTREE
> 
> If we do this, we might as well kill OF_EARLY_FLATTREE. What platform
> really boots from not FDT, but uses DT without overlays?

Making sure I'm understanding...  So you want to remove OF_EARLY_FLATTREE
and convert the current users of it to OF_FLATTREE?

I don't see any way to directly configure OF_FLATTREE and I don't see any
Kconfig file selecting it, other than drivers/of/Kconfig which selects
OF_FLATTREE from OF_EARLY_FLATTREE.  So as far as I can tell, the two
config options are essentially a single config option.  Meaning that
either one could be replaced by the other.

Changing all to OF_FLATTREE will touch more files and thus will be a
bit more obtrusive.  It looks like it would take two releases to avoid
a flag day change.

Changing all to OF_EARLY_FLATTREE can be done in a single release.

I can create a patch set whichever way you prefer.

-Frank


Re: [PATCH] ASoC: Intel: Skylake: Fix compiler warning -Wmaybe-uninitialized

2018-02-18 Thread Takashi Sakamoto

Hi,

On Feb 19 2018 15:02, Kirill Marinushkin wrote:

Configuration:

SND_SOC_INTEL_SKYLAKE=y
PM_SLEEP=y

Warning message:

sound/soc/intel/skylake/skl.c: In function 'skl_resume':
sound/soc/intel/skylake/skl.c:326:6: warning: 'ret' may be used
uninitialized in this function [-Wmaybe-uninitialized]
   int ret;
   ^~~

Fixes: 4557c305d4fc ("ASoC: Intel: Skylake: Add support for active suspend")
Signed-off-by: Kirill Marinushkin 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Vinod Koul 
Cc: Guneshwor Singh 
Cc: Naveen Manohar 
Cc: Harsha Priya N 
Cc: Pierre-Louis Bossart 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
  sound/soc/intel/skylake/skl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index 31d8634e8aa1..273a9ab75489 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -323,7 +323,7 @@ static int skl_resume(struct device *dev)
struct skl *skl  = ebus_to_skl(ebus);
struct hdac_bus *bus = ebus_to_hbus(ebus);
struct hdac_ext_link *hlink = NULL;
-   int ret;
+   int ret = 0;
  
  	/* Turned OFF in HDMI codec driver after codec reconfiguration */

if (IS_ENABLED(CONFIG_SND_SOC_HDAC_HDMI)) {


At current HEAD (ea954fbc35e6) in 'topic/intel' branch[1] of Mark's 
tree, this issue was already fixed by Arnd Bergmann Nov 2017 by his 
commit cc20c4df1627 ('ASoC: intel: initialize return value properly')[2].



[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/log/?h=topic/intel
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=topic/intel=cc20c4df1627


Regards

Takashi Sakamoto


Re: [PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

2018-02-18 Thread kbuild test robot
Hi Tony,

I love your patch! Perhaps something to improve:

[auto build test WARNING on phy/next]
[also build test WARNING on v4.16-rc2 next-20180216]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tony-Lindgren/phy-mapphone-mdm6600-Add-USB-PHY-driver-for-MDM6600-on-Droid-4/20180219-131127
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/phy/motorola/phy-mapphone-mdm6600.c:354:24: sparse: incompatible 
>> types for operation (>=)
   drivers/phy/motorola/phy-mapphone-mdm6600.c:354:24: left side has type 
struct gpio_desc
   drivers/phy/motorola/phy-mapphone-mdm6600.c:354:24: right side has type int
>> drivers/phy/motorola/phy-mapphone-mdm6600.c:354:24: sparse: incorrect type 
>> in conditional
   drivers/phy/motorola/phy-mapphone-mdm6600.c:354:24: got bad type

vim +354 drivers/phy/motorola/phy-mapphone-mdm6600.c

   340  
   341  /**
   342   * phy_mdm6600_device_power_off() - power off mdm6600 device
   343   * @ddata: device driver data
   344   */
   345  static void phy_mdm6600_device_power_off(struct phy_mdm6600 *ddata)
   346  {
   347  struct gpio_desc *reset_gpio =
   348  ddata->gpio[PHY_MDM6600_RESET];
   349  
   350  ddata->enabled = false;
   351  phy_mdm6600_cmd(ddata, AP_STATUS_BP_SHUTDOWN_REQ);
   352  msleep(100);
   353  
 > 354  if (reset_gpio >= 0)
   355  gpiod_set_value_cansleep(reset_gpio, 1);
   356  
   357  dev_info(ddata->dev, "Waiting for power down request to 
complete.. ");
   358  if (wait_for_completion_timeout(>ack,
   359  msecs_to_jiffies(5000))) {
   360  dev_info(ddata->dev, "Powered down OK\n");
   361  } else {
   362  dev_err(ddata->dev, "Timed out powering down\n");
   363  }
   364  }
   365  

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


[PATCH] ASoC: Intel: Skylake: Fix compiler warning -Wmaybe-uninitialized

2018-02-18 Thread Kirill Marinushkin
Configuration:

SND_SOC_INTEL_SKYLAKE=y
PM_SLEEP=y

Warning message:

sound/soc/intel/skylake/skl.c: In function 'skl_resume':
sound/soc/intel/skylake/skl.c:326:6: warning: 'ret' may be used
uninitialized in this function [-Wmaybe-uninitialized]
  int ret;
  ^~~

Fixes: 4557c305d4fc ("ASoC: Intel: Skylake: Add support for active suspend")
Signed-off-by: Kirill Marinushkin 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Vinod Koul 
Cc: Guneshwor Singh 
Cc: Naveen Manohar 
Cc: Harsha Priya N 
Cc: Pierre-Louis Bossart 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/intel/skylake/skl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index 31d8634e8aa1..273a9ab75489 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -323,7 +323,7 @@ static int skl_resume(struct device *dev)
struct skl *skl  = ebus_to_skl(ebus);
struct hdac_bus *bus = ebus_to_hbus(ebus);
struct hdac_ext_link *hlink = NULL;
-   int ret;
+   int ret = 0;
 
/* Turned OFF in HDMI codec driver after codec reconfiguration */
if (IS_ENABLED(CONFIG_SND_SOC_HDAC_HDMI)) {
-- 
2.13.6



500 ms delay in time saved into RTC

2018-02-18 Thread Igor Plyatov

Hi!

I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel 
and RTC chip DS1340 (rtc-ds1307.c driver).


RTC chip connected by means of I2C-bus, without HW IRQ line connected.

Kernel configured to not use embedded functions for time getting at 
startup and saving at shutdown:

CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_DS1307_CENTURY=y

The hwclock utility is from util-linux-2.29.1.

The OS does not have external time synchronization sources like NTP, PTP 
or else.


Generally I need to achieve error within +-20 ms when RTC's time copied 
into OS or back from OS into RTC.


I have made measurements during startup and shutdown of OS and have 
found 500 ms delay introduced into RTC's time, when "hwclock --utc 
--systohc" executed.


Logical analyzer show to me I2C-bus transactions and PPS signal 
generated by Linux. And I see 500 ms delay is between of rising edge of 
PPS signal (start of OS second) and moment when time saved into RTC.


Please explain, why this happens? Is this due to absence of IRQ line for 
RTC or due to a bug in the hwclock, or kernel bug or I have missed 
something else?


Best wishes.
--
Igor Plyatov


[PATCH] arm64: Fix compilation error while accessing MPIDR_HWID_BITMASK from .S files

2018-02-18 Thread Bhupesh Sharma
Since commit e1a50de37860b3a93a9d643b09638db5aff47650 (arm64: cputype:
Silence Sparse warnings), compilation of arm64 architecture is broken
with the following error messages:

  AR  arch/arm64/kernel/built-in.o
  arch/arm64/kernel/head.S: Assembler messages:
  arch/arm64/kernel/head.S:677: Error: found 'L', expected: ')'
  arch/arm64/kernel/head.S:677: Error: found 'L', expected: ')'
  arch/arm64/kernel/head.S:677: Error: found 'L', expected: ')'
  arch/arm64/kernel/head.S:677: Error: junk at end of line, first
  unrecognized character is `L'
  arch/arm64/kernel/head.S:677: Error: unexpected characters following
  instruction at operand 2 -- `movz x1,:abs_g1_s:0xff00ffUL'
  arch/arm64/kernel/head.S:677: Error: unexpected characters following
  instruction at operand 2 -- `movk x1,:abs_g0_nc:0xff00ffUL'

This patch fixes the same by using the UL() macro correctly for
assigning the MPIDR_HWID_BITMASK macro value.

Signed-off-by: Bhupesh Sharma 
---
 arch/arm64/include/asm/cputype.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index eda8c5f629fc..350c76a1d15b 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -20,7 +20,7 @@
 
 #define MPIDR_UP_BITMASK   (0x1 << 30)
 #define MPIDR_MT_BITMASK   (0x1 << 24)
-#define MPIDR_HWID_BITMASK 0xff00ffUL
+#define MPIDR_HWID_BITMASK UL(0xff00ff)
 
 #define MPIDR_LEVEL_BITS_SHIFT 3
 #define MPIDR_LEVEL_BITS   (1 << MPIDR_LEVEL_BITS_SHIFT)
-- 
2.7.4



[PATCH 1/3] dt-bindings: aspeed-lpc: Add reset controller

2018-02-18 Thread Joel Stanley
This describes the reset controller present in the LPC address space.

Signed-off-by: Joel Stanley 
---
 .../devicetree/bindings/mfd/aspeed-lpc.txt  | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
index 514d82ced95b..721a2b1eb40f 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -135,3 +135,24 @@ lhc: lhc@20 {
compatible = "aspeed,ast2500-lhc";
reg = <0x20 0x24 0x48 0x8>;
 };
+
+LPC reset control
+-
+
+The UARTs present in the ASPEED SoC can have their resets tied to the reset
+state of the LPC bus. Some systems may chose to modify this configuration.
+
+Required properties:
+
+ - comaptible: "aspeed,ast2500-lpc-reset" or
+   "aspeed,ast2400-lpc-reset"
+ - reg:offset and length of the IP in the LHC memory 
region
+ - #reset-controller   indacates the number of reset cells excepted
+
+Example:
+
+lpc_reset: reset-controller@18 {
+compatible = "aspeed,ast2500-lpc-reset";
+reg = <0x18 0x4>;
+#reset-cells = <1>;
+};
-- 
2.15.1



[PATCH 0/3] reset: simple: enable for ASPEED SoCs

2018-02-18 Thread Joel Stanley
Hello Philip,

Here is a series that enables the simple reset driver for the ASPEED
SoCs. You may recall I posted a patch back in May 2017 with a
similar idea[1]. I was happy to see that you merged a driver that solves
the problem, and suits our purpose for the ASPEED. Thanks!

Cheers,

Joel

[1] https://lkml.org/lkml/2017/5/25/940


Joel Stanley (3):
  dt-bindings: aspeed-lpc: Add reset controller
  reset: simple: Enable for ASPEED systems
  reset: simple: Allow user selection of driver

 .../devicetree/bindings/mfd/aspeed-lpc.txt  | 21 +
 drivers/reset/Kconfig   | 12 
 drivers/reset/reset-simple.c|  2 ++
 3 files changed, 31 insertions(+), 4 deletions(-)

-- 
2.15.1



Re: [PATCH 2/8] lightnvm: show generic geometry in sysfs

2018-02-18 Thread Matias Bjørling

On 02/16/2018 07:35 AM, Javier Gonzalez wrote:



On 15 Feb 2018, at 02.20, Matias Bjørling  wrote:

On 02/13/2018 03:06 PM, Javier González wrote:

From: Javier González 
Apart from showing the geometry returned by the different identify
commands, provide the generic geometry too, as this is the geometry that
targets will use to describe the device.
Signed-off-by: Javier González 
---
  drivers/nvme/host/lightnvm.c | 146 ---
  1 file changed, 97 insertions(+), 49 deletions(-)
diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 97739e668602..7bc75182c723 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -944,8 +944,27 @@ static ssize_t nvm_dev_attr_show(struct device *dev,
return scnprintf(page, PAGE_SIZE, "%u.%u\n",
dev_geo->major_ver_id,
dev_geo->minor_ver_id);
-   } else if (strcmp(attr->name, "capabilities") == 0) {
-   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.cap);
+   } else if (strcmp(attr->name, "clba") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.clba);
+   } else if (strcmp(attr->name, "csecs") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.csecs);
+   } else if (strcmp(attr->name, "sos") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.sos);
+   } else if (strcmp(attr->name, "ws_min") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.ws_min);
+   } else if (strcmp(attr->name, "ws_opt") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.ws_opt);
+   } else if (strcmp(attr->name, "maxoc") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.maxoc);
+   } else if (strcmp(attr->name, "maxocpu") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.maxocpu);
+   } else if (strcmp(attr->name, "mw_cunits") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mw_cunits);
+   } else if (strcmp(attr->name, "media_capabilities") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mccap);
+   } else if (strcmp(attr->name, "max_phys_secs") == 0) {
+   return scnprintf(page, PAGE_SIZE, "%u\n",
+   ndev->ops->max_phys_sect);
} else if (strcmp(attr->name, "read_typ") == 0) {
return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.trdt);
} else if (strcmp(attr->name, "read_max") == 0) {
@@ -984,19 +1003,8 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
attr = >attr;
  - if (strcmp(attr->name, "vendor_opcode") == 0) {
-   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.vmnt);
-   } else if (strcmp(attr->name, "device_mode") == 0) {
-   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.dom);
-   /* kept for compatibility */
-   } else if (strcmp(attr->name, "media_manager") == 0) {
-   return scnprintf(page, PAGE_SIZE, "%s\n", "gennvm");
-   } else if (strcmp(attr->name, "ppa_format") == 0) {
+   if (strcmp(attr->name, "ppa_format") == 0) {
return nvm_dev_attr_show_ppaf((void *)_geo->c.addrf, page);
-   } else if (strcmp(attr->name, "media_type") == 0) {/* u8 */
-   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mtype);
-   } else if (strcmp(attr->name, "flash_media_type") == 0) {
-   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.fmtype);
} else if (strcmp(attr->name, "num_channels") == 0) {
return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->num_ch);
} else if (strcmp(attr->name, "num_luns") == 0) {
@@ -1011,8 +1019,6 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.fpg_sz);
} else if (strcmp(attr->name, "hw_sector_size") == 0) {
return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.csecs);
-   } else if (strcmp(attr->name, "oob_sector_size") == 0) {/* u32 */
-   return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.sos);
} else if (strcmp(attr->name, "prog_typ") == 0) {
return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tprt);
} else if (strcmp(attr->name, "prog_max") == 0) {
@@ -1021,13 +1027,21 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tbet);
} else if (strcmp(attr->name, "erase_max") == 0) {
return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tbem);
+   } else if (strcmp(attr->name, "vendor_opcode") == 0) {
+   return 

Re: [PATCH] auxdisplay: Replace licenses with SPDX identifiers

2018-02-18 Thread Geert Uytterhoeven
On Sat, Feb 17, 2018 at 8:39 PM, Miguel Ojeda
 wrote:
> Signed-off-by: Miguel Ojeda 

For:
>  drivers/auxdisplay/hd44780.c|  6 +-

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

2018-02-18 Thread Christophe LEROY



Le 18/02/2018 à 18:14, Horia Geantă a écrit :

On 2/17/2018 6:32 PM, Christophe LEROY wrote:



Le 07/02/2018 à 15:39, Horia Geantă a écrit :

On 10/6/2017 4:06 PM, Christophe Leroy wrote:

At every request, we map and unmap the same hash hw_context.

This patch moves the dma mapping/unmapping in functions ahash_init()
and ahash_import().

Signed-off-by: Christophe Leroy 
---
   drivers/crypto/talitos.c | 80 
++--
   1 file changed, 57 insertions(+), 23 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index ebfd6d982ed6..d495649d5267 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -819,6 +819,7 @@ struct talitos_ctx {
unsigned int keylen;
unsigned int enckeylen;
unsigned int authkeylen;
+   dma_addr_t dma_hw_context;

This doesn't look correct.

talitos_ctx structure is the tfm context.
dma_hw_context is the IOVA of hw_context, located in talitos_ahash_req_ctx
structure (request context).


Yes but I have now found how I can know that the request context is
being released in order to unmap() dma at that time.
It is tricky to use the tmf context I agree, but at least I know when
tmf context get destroyed, ie in talitos_cra_exit_ahash()
The request context is created by ahash_request_alloc() and released by
ahash_request_free(). I have not found the way to call dma_unmap()
before ahash_request_free() gets called.



If there are multiple requests in flight for the same tfm, dma_hw_context will
be overwritten.


Before overwritting dma_hw_context, it is always released, see
talitos_cra_exit_ahash(), ahash_init(), ahash_import()


The problem is not the unmapping.
If there are two requests for the same tfm, then given the following sequence
1. tfm->ahash_init(req1)
tfm_ctx->dma_hw_context points to req1_ctx->hw_context
2. tfm->ahash_init(req2)
tfm_ctx->dma_hw_context [unmapped, then] points to req2_ctx->hw_context
i.e. req1 will use the hw_context of req2.



dma_hw_context needs to be moved in request context (talitos_ahash_req_ctx 
struct).


Any suggestion then on how to handle the issue explained above ?


There is no ahash_exit() callback mirroring ahash_init().

The clean-up of request ctx should be done in the last states of the hash flows
described here:
https://www.kernel.org/doc/html/latest/crypto/devel-algos.html#cipher-definition-with-struct-shash-alg-and-ahash-alg
for e.g. in the final() callback.


Unfortunatly it seems that we can't rely on those finalising functions 
being called all the time.
If you look into test_ahash_jiffies() for instance, in case of error the 
call of crypto_hash_final() is skipped.
So at the time being, I can't see any place to put the unmapping to be 
100% sure it will be done before the call of ahash_request_free()


Christophe



Hope this helps,
Horia



Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

2018-02-18 Thread Michael Ellerman
Arnaldo Carvalho de Melo  writes:

> Em Fri, Feb 16, 2018 at 02:29:01PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Humm, we need to create two tables, one for 32-bit and another for 64,
>> even with ppc not having (AFAIK) clashes in syscall numbers for 32/64...
>> 
>> Trying to do it now.
>
> Now seems to work, take a look at my perf/core branch, should be one of the 
> first few csets.

LGTM. Thanks for fixing this up.

cheers

> perfbuilder@cc1a85517216:/git/perf$ grep 192 
> /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_32.c 
>   [192] = "mmap2",
> perfbuilder@cc1a85517216:/git/perf$ powerpc-linux-gnu-gcc --version
> powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> perfbuilder@cc1a85517216:/git/perf$
>
> perfbuilder@9d7fc9dcfb73:/git/perf$ grep 192 
> /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_32.c
>   [192] = "mmap2",
> perfbuilder@9d7fc9dcfb73:/git/perf$ grep 192 
> /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_64.c
> perfbuilder@9d7fc9dcfb73:/git/perf$ powerpc64-linux-gnu-gcc --version
> powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609
> perfbuilder@9d7fc9dcfb73:/git/perf$ 


Re: [PATCH 11/23] kconfig: add 'shell-stdout' function

2018-02-18 Thread Ulf Magnusson
On Fri, Feb 16, 2018 at 11:17:52AM -0800, Linus Torvalds wrote:
> On Fri, Feb 16, 2018 at 10:38 AM, Masahiro Yamada
>  wrote:
> > This is the second built-in function, which retrieves the first line
> > of stdout from the given shell command.
> 
> This is the only part I really don't much like in your patch series.
> 
> Most of it is just lovely and looks very nice and powerful, but the
> difference between "$(shell ..." and "$(shell-stdout ..." to me is
> bvery ugly.
> 
> Can we *please* make "shell-stdout" go away, and make this just be "shell"?
> 
> The rule would be very simple:
> 
>  - if the result of the shell command is a failure, the result is 'n'
> 
>  - otherwise, the result is the first line of stdout
> 
>  - if the result is empty, we replace it with 'y'.
> 
> So doing $(shell true) would be 100% equivalent to $(shell echo y),
> and you could still do that
> 
>   default $(shell $CC --version | grep -q gcc)
> 
> because it would just automatically do the right thing.
> 
> Basically, the only difference is how $(shell ) works in the success
> case: the result won't necessarily be 'y', it will be whatever output.
> But if you want to always turn it into 'y' (say, you don't have a "-q"
> flag for the grep equivalent above), you can always do so with
> 
>   default $(shell $CC --version | noqgrep gcc > /dev/null)
> 
> So it seems to me that there is never any fundamental reason why we'd
> want both "shell" and "shell-stdout", since "shell-stdout" is
> fundamentally more powerful than "shell", and can always be used as
> such (and just renamed to "shell").
> 
> Because I really think that it's just much prettier and more intuitive
> to be able to say
> 
> default "/boot/config-$(shell uname --release)"
> 
> without that "-stdout" thing.
> 
> Hmm?
> 
> But I do want to say how much I liked this series. Just this part
> seemed to result in uglier Kconfig scripts.
> 
>  Linus

Could there be cases where you'd legitimately want to put empty output
from a command in a string (that would be common enough to matter)?
That'd get messier with the above rule, as it never generates an empty
string as output.

For an environment variable, stuff like prefixes come to mind, but I
can't think of anything for a command. I'm more familiar with Kconfig
than the rest of the kernel build system though.


Would you still be as opposed (or more opposed...) to having two
functions if they were called something like 'success' and 'stdout'
instead?

This reads pretty naturally to me:

config CC_IS_GCC
def_bool "$(success $CC --version | grep gcc)"

As does this:

default "/boot/config-$(stdout uname --release)"

The rule for $(success ...) would be that it's textually replaced by "y"
if the exit status of the command is 0, and with "n" in all other cases.

$(stdout ...) would be textually replaced by the first line from stdout.
Maybe it'd be helpful to spit out a warning if the exit status is non-0.

All functions would just do dumb and simple-to-understand text
replacement, and all the interpretation would happen later in the normal
way. Enforcing the quotes would make this behavior obvious. That would
indirectly turn the expanded values into constant symbols internally in
Kconfig.

Thoughts?

Cheers,
Ulf


Re: [PATCH v4] perf ftrace: Append an EOL when write tracing files

2018-02-18 Thread Namhyung Kim
On Mon, Feb 19, 2018 at 10:33:29AM +0800, changbin...@intel.com wrote:
> From: Changbin Du 
> 
> Before this change, the '--graph-funcs', '--nograph-funcs' and
> '--trace-funcs' options didn't work as expected when the  doesn't
> exist. Because the kernel side hid possible errors.
> 
> $ sudo ./perf ftrace -a --graph-depth 1 --graph-funcs abcdefg
>  0)   0.140 us|  rcu_all_qs();
>  3)   0.304 us|  mutex_unlock();
>  0)   0.153 us|  find_vma();
>  3)   0.088 us|  __fsnotify_parent();
>  0)   6.145 us|  handle_mm_fault();
>  3)   0.089 us|  fsnotify();
>  3)   0.161 us|  __sb_end_write();
>  3)   0.710 us|  SyS_close();
>  3)   7.848 us|  exit_to_usermode_loop();
> 
> On above example, I specified function filter 'abcdefg' but all functions
> are enabled. The expected error is hidden.
> 
> The original fix is to make the kernel support '\0' as end of string:
> https://lkml.org/lkml/2018/1/16/116
> 
> But above fix cannot be compatible with old kernels. Then Namhyung Kim
> suggest adding a space after function name.
> 
> This patch will append an '\n' when write tracing file. After this fix,
> the perf will report correct error state. Also let it print an error if
> reset_tracing_files() fails.
> 
> Cc: Namhyung Kim 
> Signed-off-by: Changbin Du 

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> 
> ---
> v4: check strdup() return. (Kim)
> v3: Took Kim's suggestion that add a space after function name.
> v2: Rebase.
> ---
>  tools/perf/builtin-ftrace.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
> index 25a42ac..f42f228 100644
> --- a/tools/perf/builtin-ftrace.c
> +++ b/tools/perf/builtin-ftrace.c
> @@ -72,6 +72,7 @@ static int __write_tracing_file(const char *name, const 
> char *val, bool append)
>   ssize_t size = strlen(val);
>   int flags = O_WRONLY;
>   char errbuf[512];
> + char *val_copy;
>  
>   file = get_tracing_file(name);
>   if (!file) {
> @@ -91,12 +92,23 @@ static int __write_tracing_file(const char *name, const 
> char *val, bool append)
>   goto out;
>   }
>  
> - if (write(fd, val, size) == size)
> + /*
> +  * Copy the original value and append a '\n'. Without this,
> +  * the kernel can hide possible errors.
> +  */
> + val_copy = strdup(val);
> + if (!val_copy)
> + goto out_close;
> + val_copy[size] = '\n';
> +
> + if (write(fd, val_copy, size + 1) == size + 1)
>   ret = 0;
>   else
>   pr_debug("write '%s' to tracing/%s failed: %s\n",
>val, name, str_error_r(errno, errbuf, sizeof(errbuf)));
>  
> + free(val_copy);
> +out_close:
>   close(fd);
>  out:
>   put_tracing_file(file);
> @@ -280,8 +292,10 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int 
> argc, const char **argv)
>   signal(SIGCHLD, sig_handler);
>   signal(SIGPIPE, sig_handler);
>  
> - if (reset_tracing_files(ftrace) < 0)
> + if (reset_tracing_files(ftrace) < 0) {
> + pr_err("failed to reset ftrace\n");
>   goto out;
> + }
>  
>   /* reset ftrace buffer */
>   if (write_tracing_file("trace", "0") < 0)
> -- 
> 2.7.4
> 


[PATCH 2/2] ASoC: topology: Add missing clock gating parameter when parsing hw_configs

2018-02-18 Thread Kirill Marinushkin
Clock gating parameter is a part of `dai_fmt`. It is supported by
`alsa-lib` when creating a topology binary file, but ignored by kernel
when loading this topology file.

After applying this commit, the clock gating parameter is not ignored any
more. The old behaviour is not broken, as by default the parameter value
is 0.

For example, the following config, based on
alsa-lib/src/conf/topology/broadwell/broadwell.conf, is now supported:


SectionHWConfig."CodecHWConfig" {
id "1"
format "I2S"# physical audio format.
bclk   "master" # Platform is master of bit clock
fsync  "master" # platform is master of fsync
pm_cont_clock "true"# clock is continuous, and can not be gated
}

SectionLink."Codec" {

# used for binding to the physical link
id "0"

hw_configs [
"CodecHWConfig"
]

default_hw_conf_id "1"
}


Signed-off-by: Kirill Marinushkin 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/soc-topology.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c
index 01a50413c66f..21bd4f96348d 100644
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -1981,6 +1981,12 @@ static void set_link_hw_format(struct snd_soc_dai_link 
*link,
 
link->dai_fmt = hw_config->fmt & SND_SOC_DAIFMT_FORMAT_MASK;
 
+   /* clock gating */
+   if (hw_config->clock_cont)
+   link->dai_fmt |= SND_SOC_DAIFMT_CONT;
+   else
+   link->dai_fmt |= SND_SOC_DAIFMT_GATED;
+
/* clock signal polarity */
invert_bclk = hw_config->invert_bclk;
invert_fsync = hw_config->invert_fsync;
-- 
2.13.6



[PATCH 1/2] ASoC: topology: Rename clock_gated to clock_cont in snd_soc_tplg_hw_config

2018-02-18 Thread Kirill Marinushkin
In kernel `soc-dai.h`, DAI clock gating is defined as following:


\#define SND_SOC_DAIFMT_CONT(1 << 4) /* continuous clock */
\#define SND_SOC_DAIFMT_GATED   (0 << 4) /* clock is gated */


Therefore, the corresponding field of struct snd_soc_tplg_hw_config should
be inverted compared to the current logic:

clock_count = 1 => SND_SOC_DAIFMT_CONT
clock_count = 0 => SND_SOC_DAIFMT_GATED

Signed-off-by: Kirill Marinushkin 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 include/uapi/sound/asoc.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h
index 69c37ecbff7e..10188850dede 100644
--- a/include/uapi/sound/asoc.h
+++ b/include/uapi/sound/asoc.h
@@ -312,7 +312,9 @@ struct snd_soc_tplg_hw_config {
__le32 size;/* in bytes of this structure */
__le32 id;  /* unique ID - - used to match */
__le32 fmt; /* SND_SOC_DAI_FORMAT_ format value */
-   __u8 clock_gated;   /* 1 if clock can be gated to save power */
+   __u8 clock_cont;/* 1 if clock is continuous, and can not be
+* gated to save power
+*/
__u8 invert_bclk;   /* 1 for inverted BCLK, 0 for normal */
__u8 invert_fsync;  /* 1 for inverted frame clock, 0 for normal */
__u8 bclk_master;   /* 1 for master of BCLK, 0 for slave */
-- 
2.13.6



Re: [PATCH v3 4/4] of: improve reporting invalid overlay target path

2018-02-18 Thread Frank Rowand
On 02/18/18 19:21, Rob Herring wrote:
> On Wed, Feb 14, 2018 at 09:35:46PM -0800, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>>
>> Errors while developing the patch to create of_overlay_fdt_apply()
>> exposed inadequate error messages to debug problems when overlay
>> devicetree fragment nodes contain an invalid target path.  Improve
>> the messages in find_target_node() to remedy this.
>>
>> Signed-off-by: Frank Rowand 
>> ---
>>
>> changes from v2:
>>   - add fragment node name as suggested by Geert
>>   - existing error message printed short node name, thus not
>> discriminating between fragments; change to full node name
>>   - existing error message printed node address, which is devicetree
>> internal debugging, not useful in an overlay apply error message;
>> remove node address from message
>>
>>  drivers/of/overlay.c | 22 --
>>  1 file changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
>> index 5f6c5569e97d..852e566d7744 100644
>> --- a/drivers/of/overlay.c
>> +++ b/drivers/of/overlay.c
>> @@ -488,20 +488,30 @@ static int build_changeset(struct overlay_changeset 
>> *ovcs)
>>   */
>>  static struct device_node *find_target_node(struct device_node *info_node)
>>  {
>> +struct device_node *node;
>>  const char *path;
>>  u32 val;
>>  int ret;
>>  
>>  ret = of_property_read_u32(info_node, "target", );
>> -if (!ret)
>> -return of_find_node_by_phandle(val);
>> +if (!ret) {
>> +node = of_find_node_by_phandle(val);
>> +if (!node)
>> +pr_err("find target, node: %pOF, phandle 0x%x not 
>> found\n",
> 
> I'm wondering if the core should print the error rather than having all 
> the callers do it. The question is whether there are cases where failing 
> is okay? I guess sometimes we use 0 to skip cells, but the core handle 
> not printing an error in that case.

find_target_node() is overlay specific, and is only called from one location
in overlay.c.

There are no cases where failing is ok.  This is used to find the target
node that an overlay fragment is being applied to.  If it fails then
either the base devicetree or the overlay devicetree has an error.

-Frank


> Rob
> 
>> +   info_node, val);
>> +return node;
>> +}
>>  
>>  ret = of_property_read_string(info_node, "target-path", );
>> -if (!ret)
>> -return of_find_node_by_path(path);
>> +if (!ret) {
>> +node =  of_find_node_by_path(path);
>> +if (!node)
>> +pr_err("find target, node: %pOF, path '%s' not found\n",
>> +   info_node, path);
>> +return node;
>> +}
>>  
>> -pr_err("Failed to find target for node %p (%s)\n",
>> -info_node, info_node->name);
>> +pr_err("find target, node: %pOF, no target property\n", info_node);
>>  
>>  return NULL;
>>  }
>> -- 
>> Frank Rowand 
>>
> 



Re: 500 ms delay in time saved into RTC

2018-02-18 Thread Rasmus Villemoes
On 2018-02-19 07:40, Igor Plyatov wrote:
> Hi!
> 
> I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel
> and RTC chip DS1340 (rtc-ds1307.c driver).
> 
> RTC chip connected by means of I2C-bus, without HW IRQ line connected.
> 
> Kernel configured to not use embedded functions for time getting at
> startup and saving at shutdown:
> CONFIG_RTC_CLASS=y
> # CONFIG_RTC_HCTOSYS is not set
> # CONFIG_RTC_SYSTOHC is not set
> CONFIG_RTC_INTF_DEV_UIE_EMUL=y
> CONFIG_RTC_DRV_DS1307=y
> CONFIG_RTC_DRV_DS1307_CENTURY=y
> 
> The hwclock utility is from util-linux-2.29.1.
> 
> The OS does not have external time synchronization sources like NTP, PTP
> or else.
> 
> Generally I need to achieve error within +-20 ms when RTC's time copied
> into OS or back from OS into RTC.
> 
> I have made measurements during startup and shutdown of OS and have
> found 500 ms delay introduced into RTC's time, when "hwclock --utc
> --systohc" executed.
> 
> Logical analyzer show to me I2C-bus transactions and PPS signal
> generated by Linux. And I see 500 ms delay is between of rising edge of
> PPS signal (start of OS second) and moment when time saved into RTC.
> 
> Please explain, why this happens? Is this due to absence of IRQ line for
> RTC or due to a bug in the hwclock, or kernel bug or I have missed
> something else?

cc += util-li...@vger.kernel.org

It's because util-linux's hwclock still assumes the world is x86. See
this comment in the util-linux source code:

/*
 * The Hardware Clock can only be set to any integer time plus one
 * half second.  The integer time is required because there is no
 * interface to set or get a fractional second.  The additional half
 * second is because the Hardware Clock updates to the following
 * second precisely 500 ms (not 1 second!) after you release the
 * divider reset (after setting the new time) - see description of
 * DV2, DV1, DV0 in Register A in the MC146818A data sheet (and note

So if hwclock is asked to --systohc at time 01:02:03.x, it waits until
the time is 01:02:03.5 to set the rtc to 01:02:03, or if that has
already passed, waits until  01:02:04.5 and sets it to 01:02:04.

On our ARM BSP we patch util-linux to have the "implicit fractional
part" configurable, and trying to upstream something like that has been
on my todo-list for quite a while. See

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

for the patch we currently use (on top of that, we change the 0.5
initializer to 0.0 to avoid having to always pass the --delay argument).
Incidentally, it seems we're on the same util-linux version, so you
should be able to try out that patch and see if it works for you.

Rasmus


[PATCH v2] arm64: dts: rockchip: add OPPs for rk3368-lion

2018-02-18 Thread Klaus Goger
This adds CPU operation points for the RK3368. We only add them to the
the RK3368-uQ7 SoM (Lion) because patches for the SoC where reverted
in the past.
commit 6354a06cbaa8 ("Revert "arm64: dts: rockchip: Add basic cpu
frequencies for RK3368"")

Signed-off-by: Klaus Goger 

---

 arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 80 +++
 1 file changed, 80 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
index 1315972412df..a0bcf35b1605 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
@@ -11,6 +11,70 @@
stdout-path = "serial0:115200n8";
};
 
+   cluster0_opp: opp-table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp00 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <95 95 135>;
+   clock-latency-ns = <4>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <95 95 135>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <975000 975000 135>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <105 105 135>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <115 115 135>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <141600>;
+   opp-microvolt = <130 130 135>;
+   turbo-mode;
+   };
+   opp06 {
+   opp-hz = /bits/ 64 <151200>;
+   opp-microvolt = <130 130 135>;
+   turbo-mode;
+   };
+   };
+
+   cluster1_opp: opp-table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp00 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <95 95 135>;
+   clock-latency-ns = <4>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <95 95 135>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <1025000 1025000 135>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <1125000 1125000 135>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <1225000 1225000 135>;
+   };
+   };
+
ext_gmac: gmac-clk {
compatible = "fixed-clock";
clock-frequency = <12500>;
@@ -105,35 +169,51 @@
 };
 
 _l0 {
+   clocks = < ARMCLKL>;
cpu-supply = <_cpu>;
+   operating-points-v2 = <_opp>;
 };
 
 _l1 {
+   clocks = < ARMCLKL>;
cpu-supply = <_cpu>;
+   operating-points-v2 = <_opp>;
 };
 
 _l2 {
+   clocks = < ARMCLKL>;
cpu-supply = <_cpu>;
+   operating-points-v2 = <_opp>;
 };
 
 _l3 {
+   clocks = < ARMCLKL>;
cpu-supply = <_cpu>;
+   operating-points-v2 = <_opp>;
 };
 
 _b0 {
+   clocks = < ARMCLKB>;
cpu-supply = <_cpu>;
+   operating-points-v2 = <_opp>;
 };
 
 _b1 {
+   clocks = < ARMCLKB>;
cpu-supply = <_cpu>;
+   operating-points-v2 = <_opp>;
 };
 
 _b2 {
+   clocks = < ARMCLKB>;
cpu-supply = <_cpu>;
+   operating-points-v2 = <_opp>;
 };
 
 _b3 {
+   clocks = < ARMCLKB>;
cpu-supply = <_cpu>;
+   operating-points-v2 = <_opp>;
 };
 
  {
-- 
2.11.0



[PATCH v2 3/3] misc: aspeed-lpc-ctrl: Enable FWH and A2H bridge cycles

2018-02-18 Thread Joel Stanley
To date this driver has relied on prevous state from out of tree hacks
and vendor u-boot trees in order to have the host be able to access
data over the LPC bus.

Now we explicitly enable the AHB to LPC bridge and FWH cycles from when
the user first configures the address to map. We chose to do this then
as before that time there is no way for the kernel to know where it is
safe to point the LPC window.

Tested-by: Lei YU 
Reviewed-by: Andrew Jeffery 
Signed-off-by: Joel Stanley 
---
 drivers/misc/aspeed-lpc-ctrl.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index 1827b7aa6674..a024f8042259 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -21,6 +21,10 @@
 
 #define DEVICE_NAME"aspeed-lpc-ctrl"
 
+#define HICR5 0x0
+#define HICR5_ENL2HBIT(8)
+#define HICR5_ENFWHBIT(10)
+
 #define HICR7 0x8
 #define HICR8 0xc
 
@@ -155,8 +159,18 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, 
unsigned int cmd,
if (rc)
return rc;
 
-   return regmap_write(lpc_ctrl->regmap, HICR8,
-   (~(map.size - 1)) | ((map.size >> 16) - 1));
+   rc = regmap_write(lpc_ctrl->regmap, HICR8,
+   (~(map.size - 1)) | ((map.size >> 16) - 1));
+   if (rc)
+   return rc;
+
+   /*
+* Enable LPC FHW cycles. This is required for the host to
+* access the regions specified.
+*/
+   return regmap_update_bits(lpc_ctrl->regmap, HICR5,
+   HICR5_ENFWH | HICR5_ENL2H,
+   HICR5_ENFWH | HICR5_ENL2H);
}
 
return -EINVAL;
-- 
2.15.1



[PATCH v2 0/3] misc: aspeed-lpc-ctrl fixes

2018-02-18 Thread Joel Stanley
Hi Greg,

Once Andrew has acked the bindings I think this is ready to go.

v2: Fix binding layout and add Rob's ack

These patches were developed when testing upstream Linux with OpenBMC on
Romulus. We need to ensure the LPC clock is enabled, now that the clock
driver turns off any unused clocks. We also need to enable the LPC
firmware cycles bit as we do not intend to upstream any mach-aspeed
hacks.

There was no existing binding document for the LPC host interface
controller, so I wrote one that includes the required clock description.

Joel Stanley (3):
  dt-bindings: aspeed-lpc: Document LPC Host Interface Controller
  misc: aspeed-lpc: Request and enable LPC clock
  misc: aspeed-lpc-ctrl: Enable FWH and A2H bridge cycles

 .../devicetree/bindings/mfd/aspeed-lpc.txt | 41 
 drivers/misc/aspeed-lpc-ctrl.c | 44 +++---
 2 files changed, 80 insertions(+), 5 deletions(-)

-- 
2.15.1



[PATCH v2 1/3] dt-bindings: aspeed-lpc: Document LPC Host Interface Controller

2018-02-18 Thread Joel Stanley
The LPC Host Interface Controller is part of a BMC SoC that is used for
communication with the host.

Reviewed-by: Rob Herring 
Signed-off-by: Joel Stanley 
---
v2:
 - Move the content to below the Host Node Children heading
 - Add Rob's review tag
---
 .../devicetree/bindings/mfd/aspeed-lpc.txt | 41 ++
 1 file changed, 41 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
index 514d82ced95b..69aadee00d5f 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -109,9 +109,50 @@ lpc: lpc@1e789000 {
};
 };
 
+BMC Node Children
+==
+
+
 Host Node Children
 ==
 
+LPC Host Interface Controller
+---
+
+The LPC Host Interface Controller manages functions exposed to the host such as
+LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
+management and bus snoop configuration.
+
+Required properties:
+
+- compatible:  One of:
+   "aspeed,ast2400-lpc-ctrl";
+   "aspeed,ast2500-lpc-ctrl";
+
+- reg: contains offset/length values of the host interface controller
+   memory regions
+
+- clocks:  contains a phandle to the syscon node describing the clocks.
+   There should then be one cell representing the clock to use
+
+- memory-region: A phandle to a reserved_memory region to be used for the LPC
+   to AHB mapping
+
+- flash:   A phandle to the SPI flash controller containing the flash to
+   be exposed over the LPC to AHB mapping
+
+Example:
+
+lpc-host@80 {
+   lpc_ctrl: lpc-ctrl@0 {
+   compatible = "aspeed,ast2500-lpc-ctrl";
+   reg = <0x0 0x80>;
+   clocks = < ASPEED_CLK_GATE_LCLK>;
+   memory-region = <_memory>;
+   flash = <>;
+   };
+};
+
 LPC Host Controller
 ---
 
-- 
2.15.1



[PATCH v2 2/3] misc: aspeed-lpc: Request and enable LPC clock

2018-02-18 Thread Joel Stanley
The LPC device needs to ensure it's clock is enabled before it can do
anything.

In the past the clock was enabled and left running by u-boot, however
Linux now has an upstream clock driver that disables unused clocks.

Tested-by: Lei YU 
Reviewed-by: Andrew Jeffery 
Signed-off-by: Joel Stanley 
---
 drivers/misc/aspeed-lpc-ctrl.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index b5439643f54b..1827b7aa6674 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -7,6 +7,7 @@
  * 2 of the License, or (at your option) any later version.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,7 @@
 struct aspeed_lpc_ctrl {
struct miscdevice   miscdev;
struct regmap   *regmap;
+   struct clk  *clk;
phys_addr_t mem_base;
resource_size_t mem_size;
u32 pnor_size;
@@ -221,16 +223,33 @@ static int aspeed_lpc_ctrl_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
+   lpc_ctrl->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(lpc_ctrl->clk)) {
+   dev_err(dev, "couldn't get clock\n");
+   return PTR_ERR(lpc_ctrl->clk);
+   }
+   rc = clk_prepare_enable(lpc_ctrl->clk);
+   if (rc) {
+   dev_err(dev, "couldn't enable clock\n");
+   return rc;
+   }
+
lpc_ctrl->miscdev.minor = MISC_DYNAMIC_MINOR;
lpc_ctrl->miscdev.name = DEVICE_NAME;
lpc_ctrl->miscdev.fops = _lpc_ctrl_fops;
lpc_ctrl->miscdev.parent = dev;
rc = misc_register(_ctrl->miscdev);
-   if (rc)
+   if (rc) {
dev_err(dev, "Unable to register device\n");
-   else
-   dev_info(dev, "Loaded at %pr\n", );
+   goto err;
+   }
+
+   dev_info(dev, "Loaded at %pr\n", );
+
+   return 0;
 
+err:
+   clk_disable_unprepare(lpc_ctrl->clk);
return rc;
 }
 
@@ -239,6 +258,7 @@ static int aspeed_lpc_ctrl_remove(struct platform_device 
*pdev)
struct aspeed_lpc_ctrl *lpc_ctrl = dev_get_drvdata(>dev);
 
misc_deregister(_ctrl->miscdev);
+   clk_disable_unprepare(lpc_ctrl->clk);
 
return 0;
 }
-- 
2.15.1



Re: [PATCH 1/2] ASoC: topology: Rename clock_gated to clock_cont in snd_soc_tplg_hw_config

2018-02-18 Thread Takashi Sakamoto

Hi,

On Feb 19 2018 15:05, Kirill Marinushkin wrote:

In kernel `soc-dai.h`, DAI clock gating is defined as following:


\#define SND_SOC_DAIFMT_CONT(1 << 4) /* continuous clock */
\#define SND_SOC_DAIFMT_GATED   (0 << 4) /* clock is gated */


Therefore, the corresponding field of struct snd_soc_tplg_hw_config should
be inverted compared to the current logic:

clock_count = 1 => SND_SOC_DAIFMT_CONT
clock_count = 0 => SND_SOC_DAIFMT_GATED

Signed-off-by: Kirill Marinushkin 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
  include/uapi/sound/asoc.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h
index 69c37ecbff7e..10188850dede 100644
--- a/include/uapi/sound/asoc.h
+++ b/include/uapi/sound/asoc.h
@@ -312,7 +312,9 @@ struct snd_soc_tplg_hw_config {
__le32 size;/* in bytes of this structure */
__le32 id;  /* unique ID - - used to match */
__le32 fmt; /* SND_SOC_DAI_FORMAT_ format value */
-   __u8 clock_gated;   /* 1 if clock can be gated to save power */
+   __u8 clock_cont;/* 1 if clock is continuous, and can not be
+* gated to save power
+*/
__u8 invert_bclk;   /* 1 for inverted BCLK, 0 for normal */
__u8 invert_fsync;  /* 1 for inverted frame clock, 0 for normal */
__u8 bclk_master;   /* 1 for master of BCLK, 0 for slave */


This structure was added at a commit 676c6b5208f7 ('ASoC: topology: ABI 
- Update physical DAI link configuration for version 5') in a 
development period for v4.10.


This file is a part of UAPI, thus this structure has already been 
exposed to application developers. Any change can break userspace 
applications in a point of backward compatibility for this subsystem.


It's better for you to investigate another solution for your two 
patches[1][2].



[1] [alsa-devel] [PATCH 1/2] ASoC: topology: Rename clock_gated to 
clock_cont in snd_soc_tplg_hw_config

http://mailman.alsa-project.org/pipermail/alsa-devel/2018-February/132258.html
[2] [alsa-devel] [PATCH 2/2] ASoC: topology: Add missing clock gating 
parameter when parsing hw_configs

http://mailman.alsa-project.org/pipermail/alsa-devel/2018-February/132259.html


Regards

Takashi Sakamoto


Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

2018-02-18 Thread Matias Bjørling

On 02/16/2018 07:48 AM, Javier Gonzalez wrote:



On 15 Feb 2018, at 05.11, Matias Bjørling  wrote:

The value of max_phys_sect is always static. Instead of
defining it in the nvm_dev_ops structure, declare it as a global
value.

Signed-off-by: Matias Bjørling 
---
drivers/lightnvm/core.c  | 28 +++-
drivers/lightnvm/pblk-init.c |  9 -
drivers/lightnvm/pblk-recovery.c |  8 ++--
drivers/nvme/host/lightnvm.c |  5 +
include/linux/lightnvm.h |  5 ++---
5 files changed, 16 insertions(+), 39 deletions(-)



The patch looks good, but I have a question. If a target implements the
scalar interface, then it will not be limited to 64 lbas/ppas and it
will not make sense to split the bio base don this value. In fact, it
looks like in time, we will move to a scalar interface in the 2.0 path
to align with the zoned interface, so this value will be dependent on
whether the target is using the scalar or vector interface.



Both read/write and vector interface will coexist. I am only removing 
what is hardwired into the specification.


The read/write interface has always been able issue more than 64 LBAs, 
it is instead limited by what the hardware reports its max transfer size 
to be.


[PATCH] ARM: dts: aspeed: Add LPC reset controller node

2018-02-18 Thread Joel Stanley
On both the ast2400 and ast2500 SoCs, the LPC reset controller is
required to bring the UARTs out of reset without waiting for the LPC
reset to be deasserted.

Signed-off-by: Joel Stanley 
---
Bindings and driver change is under reivew:
  https://lkml.org/lkml/2018/2/19/12

 arch/arm/boot/dts/aspeed-g4.dtsi | 10 ++
 arch/arm/boot/dts/aspeed-g5.dtsi | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 48c28a71ae7e..36ae23aa3b48 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -162,6 +162,7 @@
reg-shift = <2>;
interrupts = <9>;
clocks = < ASPEED_CLK_GATE_UART1CLK>;
+   resets = <_reset 4>;
no-loopback-test;
status = "disabled";
};
@@ -249,6 +250,12 @@
reg = <0x20 0x24 0x48 0x8>;
};
 
+   lpc_reset: reset-controller@18 {
+   compatible = 
"aspeed,ast2400-lpc-reset";
+   reg = <0x18 0x4>;
+   #reset-cells = <1>;
+   };
+
ibt: ibt@c0  {
compatible = 
"aspeed,ast2400-ibt-bmc";
reg = <0xc0 0x18>;
@@ -264,6 +271,7 @@
reg-shift = <2>;
interrupts = <32>;
clocks = < ASPEED_CLK_GATE_UART2CLK>;
+   resets = <_reset 5>;
no-loopback-test;
status = "disabled";
};
@@ -274,6 +282,7 @@
reg-shift = <2>;
interrupts = <33>;
clocks = < ASPEED_CLK_GATE_UART3CLK>;
+   resets = <_reset 6>;
no-loopback-test;
status = "disabled";
};
@@ -284,6 +293,7 @@
reg-shift = <2>;
interrupts = <34>;
clocks = < ASPEED_CLK_GATE_UART4CLK>;
+   resets = <_reset 7>;
no-loopback-test;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 8eac57c33880..17ee0fa33a14 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -205,6 +205,7 @@
reg-shift = <2>;
interrupts = <9>;
clocks = < ASPEED_CLK_GATE_UART1CLK>;
+   resets = <_reset 4>;
no-loopback-test;
status = "disabled";
};
@@ -299,6 +300,12 @@
reg = <0x20 0x24 0x48 0x8>;
};
 
+   lpc_reset: reset-controller@18 {
+   compatible = 
"aspeed,ast2500-lpc-reset";
+   reg = <0x18 0x4>;
+   #reset-cells = <1>;
+   };
+
ibt: ibt@c0 {
compatible = 
"aspeed,ast2500-ibt-bmc";
reg = <0xc0 0x18>;
@@ -314,6 +321,7 @@
reg-shift = <2>;
interrupts = <32>;
clocks = < ASPEED_CLK_GATE_UART2CLK>;
+   resets = <_reset 5>;
no-loopback-test;
status = "disabled";
};
@@ -324,6 +332,7 @@
reg-shift = <2>;
interrupts = <33>;
clocks = < ASPEED_CLK_GATE_UART3CLK>;
+   resets = <_reset 6>;
no-loopback-test;
status = "disabled";
};
@@ -334,6 +343,7 @@
reg-shift = <2>;
interrupts = <34>;
clocks = < 

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

2018-02-18 Thread Colin Ian King
On 18/02/18 16:31, Joe Perches wrote:
> On Sun, 2018-02-18 at 16:58 +0200, Andy Shevchenko wrote:
>> On Fri, Feb 16, 2018 at 6:53 PM, Colin Ian King
>>  wrote:
>>> On 16/02/18 16:51, Andy Shevchenko wrote:
 On Thu, Feb 15, 2018 at 9:42 PM, Colin King  
 wrote:
> +   filter->f.mask.tcp_spec.dst_ip[i] |=
> 
> cpu_to_be32(0x);

 Can it be one line then?
>>>
>>> I re-adjusted the text because checkpatch was complaining.

> +   filter->f.mask.tcp_spec.src_ip[i] |=
> 
> cpu_to_be32(0x);
>>
>> For the rest OK, but for the above two how much over 80 it went if
>> would be one line?
>> If it 2-3 characters, consider to make it one line. It would increase
>> readability.
> 
> Another possibility would be to use temporaries for
>   filter->f.mask.tcp_spec
> and
>   filter->f.data.tcp_spec
> as both are used ~10 times in the function

That's a good idea. I'll fix this up tomorrow when I get back to work
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



Re: [PATCH] auxdisplay: Replace licenses with SPDX identifiers

2018-02-18 Thread Philippe Ombredanne
Miguel,

On Sat, Feb 17, 2018 at 8:39 PM, Miguel Ojeda
 wrote:
> Cc: Willy Tarreau 
> Cc: Geert Uytterhoeven 
> Cc: Linus Walleij 
> Cc: Robin van der Gracht 
> Cc: Paul Burton 
> Signed-off-by: Miguel Ojeda 
> ---



> diff --git a/include/linux/cfag12864b.h b/include/linux/cfag12864b.h
> index b454dfce60d9..aa960efc32f6 100644
> --- a/include/linux/cfag12864b.h
> +++ b/include/linux/cfag12864b.h
> @@ -1,25 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0

Per the doc [1] you should be using instead this in a .h:
/* SPDX-License-Identifier: GPL-2.0 */

I know this can be surprising. This has been discussed on list quite
lot and the doc has some rationale.



> diff --git a/include/linux/ks0108.h b/include/linux/ks0108.h
> index cb311798e0bc..2a1c985fedea 100644
> --- a/include/linux/ks0108.h
> +++ b/include/linux/ks0108.h
> @@ -1,25 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0

Same comment as above.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst

-- 
Cordially
Philippe Ombredanne


Re: [PATCH] auxdisplay: Replace licenses with SPDX identifiers

2018-02-18 Thread Miguel Ojeda
On Sun, Feb 18, 2018 at 8:04 PM, Philippe Ombredanne
 wrote:
> Miguel,
>
> On Sat, Feb 17, 2018 at 8:39 PM, Miguel Ojeda
>  wrote:
>> Cc: Willy Tarreau 
>> Cc: Geert Uytterhoeven 
>> Cc: Linus Walleij 
>> Cc: Robin van der Gracht 
>> Cc: Paul Burton 
>> Signed-off-by: Miguel Ojeda 
>> ---
>
> 
>
>> diff --git a/include/linux/cfag12864b.h b/include/linux/cfag12864b.h
>> index b454dfce60d9..aa960efc32f6 100644
>> --- a/include/linux/cfag12864b.h
>> +++ b/include/linux/cfag12864b.h
>> @@ -1,25 +1,11 @@
>> +// SPDX-License-Identifier: GPL-2.0
>
> Per the doc [1] you should be using instead this in a .h:
> /* SPDX-License-Identifier: GPL-2.0 */
>
> I know this can be surprising. This has been discussed on list quite
> lot and the doc has some rationale.

Thanks for taking the time to check the patch. It was a mistake on my
side -- I had actually read the docs but I recalled Linus talking
about moving to // at some point (and somehow my brain recorded that
the discussion was about the headers :-), so I thought I was actually
doing the right thing by using // already. Don't worry, I will fix it
when I put it in the queue.

Cheers,
Miguel

>
> 
>
>> diff --git a/include/linux/ks0108.h b/include/linux/ks0108.h
>> index cb311798e0bc..2a1c985fedea 100644
>> --- a/include/linux/ks0108.h
>> +++ b/include/linux/ks0108.h
>> @@ -1,25 +1,11 @@
>> +// SPDX-License-Identifier: GPL-2.0
>
> Same comment as above.
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst
>
> --
> Cordially
> Philippe Ombredanne


Re: linux-next: Signed-off-by missing for commit in the parisc-hd tree

2018-02-18 Thread Helge Deller
On 18.02.2018 21:48, Stephen Rothwell wrote:
> Commit
>   6c2dfd2e720d ("parisc: Fix ordering of cache and TLB flushes")
> 
> is missing a Signed-off-by from its committer.

Thanks!
Fixed now.

Helge



signature.asc
Description: OpenPGP digital signature


[PATCH 0/9] ASoC: Intel: sst: Fix Bay Trail suspend/resume issues

2018-02-18 Thread Hans de Goede
Hi All,

Here is a series fixing suspend/resume errors (and broken audio after
resume) on Bay Trail devices.

Cherry Trail devices also do not like being suspend while audio is
playing, but with different sypmtoms instead of SST_ERR_INVALID_STREAM_ID
errors, if a stream was playing (being allocated is fine, playing is a
problem) before suspend then after resume we get the following errors:

  [ 2312.389974] intel_sst_acpi 808622A8:00: sst: Busy wait failed, cant send 
this msg
  [ 2312.597976] intel_sst_acpi 808622A8:00: sst: Busy wait failed, cant send 
this msg
  ...

Until the stream is stopped and restarted after which things work fine
again. I've tried enabling the quirk this commit adds for Cherry Trail
devices too, but that does not help. If anyone has any clues about the CHT
problem, please let me know.

Regards,

Hans


[PATCH 7/9] ASoc: rt5651: Fix regcache sync errors on resume

2018-02-18 Thread Hans de Goede
The ALC5651 does not like multi-write accesses, avoid them. This fixes:

rt5651 i2c-10EC5651:00: Unable to sync registers 0x27-0x28. -121

Errors on resume (and all registers after the registers in the error not
being synced).

Signed-off-by: Hans de Goede 
---
 sound/soc/codecs/rt5651.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index 831b297978a4..45a73049cf64 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -1722,6 +1722,7 @@ static const struct regmap_config rt5651_regmap = {
.num_reg_defaults = ARRAY_SIZE(rt5651_reg),
.ranges = rt5651_ranges,
.num_ranges = ARRAY_SIZE(rt5651_ranges),
+   .use_single_rw = true,
 };
 
 #if defined(CONFIG_OF)
-- 
2.14.3



[PATCH 6/9] ASoC: Intel: sst: Free streams on suspend, re-alloc on resume

2018-02-18 Thread Hans de Goede
The Bay Trail SST-DSP firmware version looses track of all streams over a
suspend/resume, failing any attempts to resume and/or free streams, with
a SST_ERR_INVALID_STREAM_ID error.

This commit adds support for free-ing the streams on suspend and
re-allocating them on resume, fixing suspend/resume issues on devices
using this firmware version.

This new behavior gets triggered by a new flag in sst_platform_info which
only gets set on Bay Trail platforms.

This has been tested on the following devices:
-Asus T100TA,Bay Trail+ ALC5642 codec
-Ployer MOMO7W,  Bay Trail CR + ALC5652 codec

Tested-by: Hans de Goede 
Signed-off-by: Hans de Goede 
---
 arch/x86/include/asm/platform_sst_audio.h |  1 +
 sound/soc/intel/atom/sst/sst.c| 24 +++-
 sound/soc/intel/atom/sst/sst.h|  4 
 sound/soc/intel/atom/sst/sst_acpi.c   |  3 ++-
 sound/soc/intel/atom/sst/sst_stream.c | 24 +++-
 5 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/platform_sst_audio.h 
b/arch/x86/include/asm/platform_sst_audio.h
index 5973a2f3db3d..059823bb8af7 100644
--- a/arch/x86/include/asm/platform_sst_audio.h
+++ b/arch/x86/include/asm/platform_sst_audio.h
@@ -135,6 +135,7 @@ struct sst_platform_info {
const struct sst_res_info *res_info;
const struct sst_lib_dnld_info *lib_info;
const char *platform;
+   bool streams_lost_on_suspend;
 };
 int add_sst_platform_device(void);
 #endif
diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
index 8afdff457579..0962bc9adc62 100644
--- a/sound/soc/intel/atom/sst/sst.c
+++ b/sound/soc/intel/atom/sst/sst.c
@@ -449,6 +449,13 @@ static int intel_sst_suspend(struct device *dev)
dev_err(dev, "stream %d is running, can't suspend, 
abort\n", i);
return -EBUSY;
}
+
+   if (ctx->pdata->streams_lost_on_suspend) {
+   stream->resume_status = stream->status;
+   stream->resume_prev = stream->prev;
+   if (stream->status != STREAM_UN_INIT)
+   sst_free_stream(ctx, i);
+   }
}
synchronize_irq(ctx->irq_num);
flush_workqueue(ctx->post_msg_wq);
@@ -509,8 +516,8 @@ static int intel_sst_resume(struct device *dev)
 {
struct intel_sst_drv *ctx = dev_get_drvdata(dev);
struct sst_fw_save *fw_save = ctx->fw_save;
-   int ret = 0;
struct sst_block *block;
+   int i, ret = 0;
 
if (!fw_save)
return 0;
@@ -550,6 +557,21 @@ static int intel_sst_resume(struct device *dev)
sst_set_fw_state_locked(ctx, SST_FW_RUNNING);
}
 
+   if (ctx->pdata->streams_lost_on_suspend) {
+   for (i = 1; i <= ctx->info.max_streams; i++) {
+   struct stream_info *stream = >streams[i];
+
+   if (stream->resume_status != STREAM_UN_INIT) {
+   dev_dbg(ctx->dev, "Re-allocing stream %d status 
%d prev %d\n",
+   i, stream->resume_status,
+   stream->resume_prev);
+   sst_realloc_stream(ctx, i);
+   stream->status = stream->resume_status;
+   stream->prev = stream->resume_prev;
+   }
+   }
+   }
+
sst_free_block(ctx, block);
return ret;
 }
diff --git a/sound/soc/intel/atom/sst/sst.h b/sound/soc/intel/atom/sst/sst.h
index a357cd615b59..b2a705dc9304 100644
--- a/sound/soc/intel/atom/sst/sst.h
+++ b/sound/soc/intel/atom/sst/sst.h
@@ -179,6 +179,8 @@ struct sst_block {
  *
  * @status : stream current state
  * @prev : stream prev state
+ * @resume_status : stream current state to restore on resume
+ * @resume_prev : stream prev state to restore on resume
  * @lock : stream mutex for protecting state
  * @alloc_param : parameters used for stream (re-)allocation
  * @pcm_substream : PCM substream
@@ -189,6 +191,8 @@ struct sst_block {
 struct stream_info {
unsigned intstatus;
unsigned intprev;
+   unsigned intresume_status;
+   unsigned intresume_prev;
struct mutexlock;
struct snd_sst_alloc_mrfld alloc_param;
 
diff --git a/sound/soc/intel/atom/sst/sst_acpi.c 
b/sound/soc/intel/atom/sst/sst_acpi.c
index 6cd481bec275..c90b04cc071d 100644
--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -143,10 +143,11 @@ static struct sst_platform_info byt_rvp_platform_data = {
.lib_info = _lib_dnld_info,
.res_info = _rvp_res_info,
.platform = "sst-mfld-platform",
+   .streams_lost_on_suspend = true,
 };
 
 /* Cherryview (Cherrytrail and Braswell) uses 

[PATCH 9/9] ASoC: Intel: bytcr_rt5651: Drop unwanted ignore_suspend settings

2018-02-18 Thread Hans de Goede
The ignore_suspend settings were added in an attempt to try and fix
suspend / resume issues. But they never fully fixed these and now we've
a proper fix, so lets remove these.

Signed-off-by: Hans de Goede 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 456526a93dd5..49c538f2770a 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -335,8 +335,6 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
dev_err(card->dev, "unable to add card controls\n");
return ret;
}
-   snd_soc_dapm_ignore_suspend(>dapm, "Headphone");
-   snd_soc_dapm_ignore_suspend(>dapm, "Speaker");
 
if (byt_rt5651_quirk & BYT_RT5651_MCLK_EN) {
/*
@@ -487,7 +485,6 @@ static struct snd_soc_dai_link byt_rt5651_dais[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
| SND_SOC_DAIFMT_CBS_CFS,
.be_hw_params_fixup = byt_rt5651_codec_fixup,
-   .ignore_suspend = 1,
.nonatomic = true,
.dpcm_playback = 1,
.dpcm_capture = 1,
-- 
2.14.3



[PATCH 8/9] ASoC: Intel: bytcr_rt5640: Drop unwanted ignore_suspend settings

2018-02-18 Thread Hans de Goede
The ignore_suspend settings were added in an attempt to try and fix
suspend / resume issues. But they never fully fixed these and now we've
a proper fix, so lets remove these.

Signed-off-by: Hans de Goede 
---
 sound/soc/intel/boards/bytcr_rt5640.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index b6a1cfeec830..c506a6e129ca 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -532,9 +532,6 @@ static int byt_rt5640_init(struct snd_soc_pcm_runtime 
*runtime)
return ret;
}
 
-   snd_soc_dapm_ignore_suspend(>dapm, "Headphone");
-   snd_soc_dapm_ignore_suspend(>dapm, "Speaker");
-
if (byt_rt5640_quirk & BYT_RT5640_MCLK_EN) {
/*
 * The firmware might enable the clock at
@@ -691,7 +688,6 @@ static struct snd_soc_dai_link byt_rt5640_dais[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
| SND_SOC_DAIFMT_CBS_CFS,
.be_hw_params_fixup = byt_rt5640_codec_fixup,
-   .ignore_suspend = 1,
.nonatomic = true,
.dpcm_playback = 1,
.dpcm_capture = 1,
-- 
2.14.3



[PATCH 4/9] ASoC: Intel: sst: Remove unused STREAM_DECODE and STREAM_RESET states

2018-02-18 Thread Hans de Goede
STREAM_DECODE is completely unused, status == STREAM_RESET was checked
for, but never set, remove both.

Signed-off-by: Hans de Goede 
---
 sound/soc/intel/atom/sst/sst.h   |  4 +---
 sound/soc/intel/atom/sst/sst_drv_interface.c | 19 ---
 2 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/sound/soc/intel/atom/sst/sst.h b/sound/soc/intel/atom/sst/sst.h
index 164b0f674c20..f4fd442080b2 100644
--- a/sound/soc/intel/atom/sst/sst.h
+++ b/sound/soc/intel/atom/sst/sst.h
@@ -65,9 +65,7 @@ enum sst_stream_states {
STREAM_UN_INIT  = 0,/* Freed/Not used stream */
STREAM_RUNNING  = 1,/* Running */
STREAM_PAUSED   = 2,/* Paused stream */
-   STREAM_DECODE   = 3,/* stream is in decoding only state */
-   STREAM_INIT = 4,/* stream init, waiting for data */
-   STREAM_RESET= 5,/* force reset on recovery */
+   STREAM_INIT = 3,/* stream init, waiting for data */
 };
 
 enum sst_ram_type {
diff --git a/sound/soc/intel/atom/sst/sst_drv_interface.c 
b/sound/soc/intel/atom/sst/sst_drv_interface.c
index 71af5449be90..6a8b253c58d2 100644
--- a/sound/soc/intel/atom/sst/sst_drv_interface.c
+++ b/sound/soc/intel/atom/sst/sst_drv_interface.c
@@ -238,16 +238,7 @@ static int sst_cdev_close(struct device *dev, unsigned int 
str_id)
return -EINVAL;
}
 
-   if (stream->status == STREAM_RESET) {
-   dev_dbg(dev, "stream in reset state...\n");
-   stream->status = STREAM_UN_INIT;
-
-   retval = 0;
-   goto put;
-   }
-
retval = sst_free_stream(ctx, str_id);
-put:
stream->compr_cb_param = NULL;
stream->compr_cb = NULL;
 
@@ -256,7 +247,6 @@ static int sst_cdev_close(struct device *dev, unsigned int 
str_id)
 
dev_dbg(dev, "End\n");
return retval;
-
 }
 
 static int sst_cdev_ack(struct device *dev, unsigned int str_id,
@@ -486,16 +476,7 @@ static int sst_close_pcm_stream(struct device *dev, 
unsigned int str_id)
return -EINVAL;
}
 
-   if (stream->status == STREAM_RESET) {
-   /* silently fail here as we have cleaned the stream earlier */
-   dev_dbg(ctx->dev, "stream in reset state...\n");
-
-   retval = 0;
-   goto put;
-   }
-
retval = free_stream_context(ctx, str_id);
-put:
stream->pcm_substream = NULL;
stream->status = STREAM_UN_INIT;
stream->period_elapsed = NULL;
-- 
2.14.3



Re: [RFC PATCH] input: Add disable sysfs entry for every input device

2018-02-18 Thread Peter Hutterer
On Sat, Feb 17, 2018 at 10:19:14PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > So, do you mean to implement this "disable" action as ioctl for
> > > > > particular /dev/input/event* device (instead of sysfs entry)?
> > > > 
> > > > Yes, so the device can be powered down without the device node being
> > > > closed and made unavailable. I don't know whether that's something
> > > > that's already possible for all cases, but there's already
> > > > opportunistic in a lot of drivers and subsystems.
> > > > 
> > > > This opens up a whole new wave of potential problems, but it's a more
> > > > generally useful mechanism, I would think.
> > > 
> > > Ok. How should API for this ioctl looks like? And do you have an idea
> > > for name of that ioctl?
> > > 
> > > Dmitry, what do you think about it? It is acceptable for you?
> > 
> > first: sysfs files are pretty terrible because writing to them requires root
> > and we don't have the benefit of logind. so for any sysfs toggle expect
> > a nicely integrated userspace solution to be less than optimal.
> 
> Well, you can chmod / chown sysfs files.

and that's what I meant by "less than optimal" :)
you're either chmodding, or suid, or any of the other solutions that aren't
really good in the long run.

> > besides: 99% of the above is figuring out the policy *when* to disable the
> > device. disabling it is trivial by just closing the evdev nodes and tbh I
> > don't think we (in userspace) should care about whether the device is
> > powered down or now, it should be the default assumption that it is powered
> > down when not in use.
> > 
> > for the cases where you must keep the device open but you don't want 
> > events, 
> > EVIOCSMASK is likely the best solution. improving the kernel so it powers
> > down the device when the mask excludes all events (and there are no other
> > listeners) could be an interesting task.
> 
> But yes, that sounds like an idea.
> 
> BTW in the meantime, someone added this to pmos wiki... this should
> solve some of my problems.
> 
> Best regards,
>   Pavel
> 
> 
> 
> FILE=~/.screenoff
> if [ -f $FILE ]; then
>  xinput set-prop 8 "Device Enabled" 1
>  xinput set-prop 6 "Device Enabled" 1
>  xinput set-prop 9 "Device Enabled" 1
>  xset dpms force on
>  rm ~/.screenoff
> else
>  xinput set-prop 8 "Device Enabled" 0
>  xinput set-prop 6 "Device Enabled" 0
>  xinput set-prop 9 "Device Enabled" 0
>  xset dpms force off
>  touch ~/.screenoff
> fi

xinput can resolve device names, using device ids is likely to cause upset.
http://who-t.blogspot.com/2016/07/xinput-resolves-device-names-and.html

Cheers,
   Peter


Re: [PATCH v3 2/4] dt-bindings: pwm-backlight: add a num-interpolation-steps property.

2018-02-18 Thread Rob Herring
On Thu, Feb 08, 2018 at 12:30:30PM +0100, Enric Balletbo i Serra wrote:
> The num-interpolated-steps property specifies the number of
> interpolated steps between each value of brightness-level table. This is
> useful for high resolution PWMs to not have to list out every possible
> value in the brightness-level array.
> 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Daniel Thompson 
> ---
> Changes since v2:
> - Add Acked-by: Daniel Thompson 
> Changes since v1:
> - Add an example with a small but realistic curve. Suggested by Rob and
>   Daniel
> 
>  .../bindings/leds/backlight/pwm-backlight.txt | 19 
> +++
>  1 file changed, 19 insertions(+)

Reviewed-by: Rob Herring 


Re: [PATCH v3] PCI: qcom: add missing supplies required for msm8996

2018-02-18 Thread Rob Herring
On Thu, Feb 15, 2018 at 01:22:48PM +, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla 
> 
> This patch adds supplies that are required for msm8996. vdda
> is analog supply that go in to controller, and vddpe_3v3 is
> supply to PCIe endpoint.
> 
> Without these supplies PCIe endpoints which require power supplies are
> not enumerated at all, as there is no one to power it up.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> changes since v2:
>   Add back empty line suggested by Stan
>   use ARRAY_SIZE
> 
>  .../devicetree/bindings/pci/qcom,pcie.txt  |  4 
>  drivers/pci/dwc/pcie-qcom.c| 23 
> +-
>  2 files changed, 26 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 


Re: [PATCH 2/3] Input: gpio-keys - allow setting wakeup interrupt trigger type in DT

2018-02-18 Thread Rob Herring
On Fri, Feb 09, 2018 at 03:42:47PM -0800, Brian Norris wrote:
> Hi Jeffy,
> 
> On Fri, Feb 09, 2018 at 07:55:09PM +0800, Jeffy Chen wrote:
> > Allow specifying a different interrupt trigger type for wakeup when
> > using the gpio-keys input device as a wakeup source.
> > 
> > Signed-off-by: Jeffy Chen 
> > ---
> > 
> >  Documentation/devicetree/bindings/input/gpio-keys.txt | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt 
> > b/Documentation/devicetree/bindings/input/gpio-keys.txt
> > index a94940481e55..61926cef708f 100644
> > --- a/Documentation/devicetree/bindings/input/gpio-keys.txt
> > +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt
> > @@ -26,6 +26,15 @@ Optional subnode-properties:
> >   If not specified defaults to 5.
> > - wakeup-source: Boolean, button can wake-up the system.
> >  (Legacy property supported: "gpio-key,wakeup")
> > +   - wakeup-trigger-type: Specifies the interrupt trigger type for wakeup.
> > +The value is defined in 
> > 
> 
> Do you really want to codify interrupt triggers here? It seems like most
> of the information about edge vs. level is already codified elsewhere,
> so this becomes a little redundant. And in fact, some bindings may be
> specifying a "gpio", not technically an interrupt (at least not
> directly), so it feels weird to apply IRQ_* flags to them right here.
> Anyway, I think he only piece you really want to describe here is, do we
> wake on "event asserted", "event deasserted", or both. (The "none" case
> would just mean you shouldn't have the "wakeup-source" property.)
> 
> So maybe:
> 
>   wakeup-trigger-type: Specifies whether the key should wake the
>   system when asserted, when deasserted, or both. This property is
>   only valid for keys that wake up the system (e.g., when the
>   "wakeup-source" property is also provided). Supported values
>   are:
> 1: asserted

As wakeup is an IRQ, that's assumed.

> 2: deasserted

Just invert the flags for the IRQ.

> 3: both asserted and deasserted

I don't see what would be the usecase. But wouldn't this be any edge 
(because level certainly doesn't make sense)?

> 
> ? We could still make macros out of those, if we want
> (input/linux-event-codes.h?). And then leave it up to the driver to
> determine how to translate that into the appropriate edge or level
> triggers.
> 
> Brian
> 
> > +Only the following flags are supported:
> > +   IRQ_TYPE_NONE
> > +   IRQ_TYPE_EDGE_RISING
> > +   IRQ_TYPE_EDGE_FALLING
> > +   IRQ_TYPE_EDGE_BOTH
> > +   IRQ_TYPE_LEVEL_HIGH
> > +   IRQ_TYPE_LEVEL_LOW
> > - linux,can-disable: Boolean, indicates that button is connected
> >   to dedicated (not shared) interrupt which can be disabled to
> >   suppress events from the button.
> > -- 
> > 2.11.0
> > 
> > 


Re: [PATCH] Documentation/process/howto: Remove outdated info about bugzilla mailing lists

2018-02-18 Thread Jonathan Corbet
On Tue, 13 Feb 2018 23:06:32 +0100
Jonathan Neuschäfer  wrote:

> The mailing list archives[1,2] show no activity since September 2011.
> 
> [1]: https://lists.linuxfoundation.org/pipermail/bugme-new/
> [2]: https://lists.linuxfoundation.org/pipermail/bugme-janitors/

Well...one wouldn't want to be too hasty here...it's only been six years
or so...:)

I went and confirmed with Konstantin that these lists are gone and not
coming back; patch applied, thanks.

jon


Re: [PATCH] Support the nonstring variable attribute (gcc >= 8)

2018-02-18 Thread Miguel Ojeda
On Mon, Feb 19, 2018 at 12:20 AM, David Rientjes  wrote:
> On Sat, 17 Feb 2018, Miguel Ojeda wrote:
>
>> From the GCC manual:
>>
>> The nonstring variable attribute specifies that an object or member
>> declaration with type array of char or pointer to char is intended to
>> store character arrays that do not necessarily contain a terminating NUL
>> character. This is useful in detecting uses of such arrays or pointers
>> with functions that expect NUL-terminated strings, and to avoid warnings
>> when such an array or pointer is used as an argument to a bounded string
>> manipulation function such as strncpy.
>>
>>   https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
>>
>> Some reports are already coming to the LKML regarding these
>> warnings. When they are false positives, we can use __nonstring to let
>> gcc know a NUL character is not required; like in this case:
>>
>>   https://lkml.org/lkml/2018/1/16/135
>>
>> Signed-off-by: Miguel Ojeda 
>> Cc: Ingo Molnar 
>> Cc: Josh Poimboeuf 
>> Cc: Kees Cook 
>> Cc: Andrew Morton 
>> Cc: Geert Uytterhoeven 
>> Cc: Will Deacon 
>> Cc: Greg Kroah-Hartman 
>> Cc: David Rientjes 
>
> I would have expected to have seen __nonstring used somewhere as part of
> this patch.

Do you mean to expand the commit message with an actual code example
instead of the links to the docs and the discussion about the report?
Otherwise, if you mean in the actual commit, I think in that case it
should be a patch series, not a single commit.

In any case, the key point here is to agree on the short-term policy:
i.e. whether we want to disable the upcoming warning or try to take
advantage of it (which not *necessarily* implies using __nonstring,
there are other workarounds; though where applicable, __nonstring is
probably the right thing to use).

[By the way, CC'ing Xiongfeng, Willy and Arnd, since they were
involved in the example report; sorry guys!].

Cheers,
Miguel


Re: [PATCH 0/6] Add support for in-line nested struct comments

2018-02-18 Thread Jonathan Corbet
On Fri, 16 Feb 2018 11:48:14 -0200
Mauro Carvalho Chehab  wrote:

> his series fix two bugs at kernel-doc.rst examples and add support
> for in-line nested struct comments.
> 
> It also converts one documentation at intel_dpio_phy to use it,
> in order to give a practical example about how to use it.

OK, I've applied everything but the last patch, which I assume will go
through the DRM tree.

Thanks,

jon


Re: linux-next: build failure after merge of the sound-asoc tree

2018-02-18 Thread Kuninori Morimoto

Hi Stephen

Thank you for your report.
It seems added new drivers are not based on new framework.
I will post fixup patch for these.

> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_da7219_init':
> sound/soc/amd/acp-da7219-max98357a.c:79:22: error: passing argument 1 of 
> 'da7219_aad_jack_det' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   da7219_aad_jack_det(codec, _jack);
>   ^
> In file included from sound/soc/amd/acp-da7219-max98357a.c:38:0:
> sound/soc/amd/../codecs/da7219-aad.h:209:6: note: expected 'struct 
> snd_soc_component *' but argument is of type 'struct snd_soc_codec *'
>  void da7219_aad_jack_det(struct snd_soc_component *component, struct 
> snd_soc_jack *jack);
>   ^~~
> cc1: some warnings being treated as errors
> sound/soc/intel/boards/kbl_da7219_max98357a.c: In function 
> 'kabylake_da7219_codec_init':
> sound/soc/intel/boards/kbl_da7219_max98357a.c:194:22: error: passing argument 
> 1 of 'da7219_aad_jack_det' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   da7219_aad_jack_det(codec, >kabylake_headset);
>   ^
> In file included from sound/soc/intel/boards/kbl_da7219_max98357a.c:23:0:
> sound/soc/intel/boards/../../codecs/da7219-aad.h:209:6: note: expected 
> 'struct snd_soc_component *' but argument is of type 'struct snd_soc_codec *'
>  void da7219_aad_jack_det(struct snd_soc_component *component, struct 
> snd_soc_jack *jack);
>   ^~~
> sound/soc/intel/boards/kbl_da7219_max98357a.c: In function 
> 'kabylake_card_late_probe':
> sound/soc/intel/boards/kbl_da7219_max98357a.c:552:34: error: passing argument 
> 1 of 'hdac_hdmi_jack_port_init' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   return hdac_hdmi_jack_port_init(codec, >dapm);
>   ^
> In file included from sound/soc/intel/boards/kbl_da7219_max98357a.c:21:0:
> sound/soc/intel/boards/../../codecs/hdac_hdmi.h:8:5: note: expected 'struct 
> snd_soc_component *' but argument is of type 'struct snd_soc_codec *'
>  int hdac_hdmi_jack_port_init(struct snd_soc_component *component,
>  ^~~~
> 
> Caused by commits
> 
>   608a300fc1f0 ("ASoC: AMD: Add machine driver for ST DA7219 MAX98357")
>   b3ea70ee64ea ("ASoC: Intel: Add Kabylake-y Dialog Maxim machine driver")
> 
> interacting with commit
> 
>   451011221711 ("ASoC: hdac_hdmi/nau8825/rt286/rt298/rt5663/da7219: replace 
> codec to component")
> 
> I have used the sound-asoc tree from next-20180216 for today.
> 
> -- 
> Cheers,
> Stephen Rothwell
> [2 OpenPGP digital signature ]
> No public key for 015042F34957D06C created at 2018-02-19T08:32:45+0900 using 
> RSA


Linux 4.16-rc2

2018-02-18 Thread Linus Torvalds
It's been a quiet week, and rc2 is out.

I take the fairly quiet rc be a good sign for 4.16, but honestly, rc2
is often fairly calm. That's probably because people are taking a
breather after the merge window, but also simply because it might take
a while to find any issues.

But let's be optimistic, and just assume - at least for now - that
it's because all is well.

The diffstat is fairly odd, but that often happens with small rc's
just because then just a couple of pulls will skew things easily in
one or two directions. This time the patch is about one third
architecture updates (arm64, x86, powerpc), one third tooling (mostly
'perf') and one third "rest". And yes, the bulk of that rest is
drivers (gpu, nvme, sound, misc), but those drivers are still
distinctly *not* the bulk of the whole patch.

Go out and test, it all looks fine.

 Linus

---

Aaron Ma (1):
  platform/x86: ideapad-laptop: Increase timeout to wait for EC answer

Aishwarya Pant (3):
  Documentation/ABI: update cpuidle sysfs documentation
  ACPI / DPTF: Document dptf_power sysfs atttributes
  ACPI: dock: document sysfs interface

Alexander Abrosimov (1):
  platform/x86: dell-laptop: Removed duplicates in DMI whitelist

Alexey Kardashevskiy (1):
  powerpc/mm: Flush radix process translations when setting MMU type

Andreas Gruenbacher (1):
  gfs2: Fixes to "Implement iomap for block_map"

Andrey Ryabinin (1):
  platform/x86: wmi: fix off-by-one write in wmi_dev_probe()

Andy Lutomirski (1):
  x86/mm: Rename flush_tlb_single() and flush_tlb_one() to
__flush_tlb_one_[user|kernel]()

Andy Shevchenko (6):
  ACPI / bus: Do not traverse through non-existed device table
  ACPI / bus: Remove checks in acpi_get_match_data()
  ACPI / bus: Rename acpi_get_match_data() to acpi_device_get_match_data()
  device property: Constify device_get_match_data()
  perf tools: Substitute yet another strtoull()
  irqdomain: Re-use DEFINE_SHOW_ATTRIBUTE() macro

Aneesh Kumar K.V (4):
  powerpc/mm: Fix crashes with 16G huge pages
  powerpc/mm/hash64: Allocate larger PMD table if hugetlb config is enabled
  powerpc/mm/hash64: Store the slot information at the right
offset for hugetlb
  powerpc/mm/hash64: Zero PGD pages on allocation

Ard Biesheuvel (1):
  crypto: sha3-generic - deal with oversize stack frames

Arnaldo Carvalho de Melo (1):
  perf evsel: Expose the perf_missing_features struct

Arnd Bergmann (2):
  x86/error_inject: Make just_return_func() globally visible
  mm: hide a #warning for COMPILE_TEST

Artem Savkov (2):
  crypto: sun4i_ss_prng - fix return value of sun4i_ss_prng_generate
  crypto: sun4i_ss_prng - convert lock to _bh in sun4i_ss_prng_generate

Balbir Singh (1):
  powerpc/mm/radix: Split linear mapping on hot-unplug

Borislav Petkov (2):
  x86/MCE: Fix build warning introduced by "x86: do not use print_symbol()"
  x86/entry/64: Remove the unused 'icebp' macro

Chris Wilson (7):
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915: Avoid truncation before clamping userspace's priority value
  drm/i915: Don't wake the device up to check if the engine is asleep
  drm/i915/breadcrumbs: Ignore unsubmitted signalers
  drm/i915: Lock out execlist tasklet while peeking inside for busy-stats
  drm/i915/pmu: Fix building without CONFIG_PM

Christian Borntraeger (1):
  virtio/s390: implement PM operations for virtio_ccw

Christoph Hellwig (4):
  dma-direct: mark as is_phys
  dma-direct: comment the dma_direct_free calling convention
  dma-mapping: fix a comment typo
  powerpc/macio: set a proper dma_coherent_mask

Colin Ian King (1):
  ocxl: fix signed comparison with less than zero

Corentin Labbe (2):
  ia64: fix build failure with CONFIG_SWIOTLB
  powerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=n

Cyril Bur (1):
  powerpc: Expose TSCR via sysfs only on powernv

Cédric Le Goater (1):
  powerpc/xive: Use hw CPU ids when configuring the CPU queues

Dan Carpenter (1):
  x86/spectre: Fix an error message

Dan Williams (4):
  x86/entry/64: Clear extra registers beyond syscall arguments, to
reduce speculation attack surface
  x86/entry/64: Clear registers for exceptions/interrupts, to
reduce speculation attack surface
  x86/entry/64/compat: Clear registers for compat syscalls, to
reduce speculation attack surface
  x86/speculation: Fix up array_index_nospec_mask() asm constraint

Daniel Mack (1):
  ALSA: usb: add more device quirks for USB DSD devices

David Woodhouse (4):
  x86/speculation: Update Speculation Control microcode blacklist
  x86/speculation: Correct Speculation Control microcode blacklist again
  Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"
  KVM/x86: Reduce retpoline performance impact in

Re: [PATCH v2 1/2] memory: tegra: Squash tegra20-mc into common tegra-mc driver

2018-02-18 Thread Dmitry Osipenko
On 13.02.2018 13:30, Thierry Reding wrote:
> On Mon, Feb 12, 2018 at 08:06:30PM +0300, Dmitry Osipenko wrote:
>> Tegra30+ has some minor differences in registers / bits layout compared
>> to Tegra20. Let's squash Tegra20 driver into the common tegra-mc driver
>> to reduce code a tad, this also will be useful for the upcoming Tegra's MC
>> reset API.
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/memory/Kconfig |  10 --
>>  drivers/memory/Makefile|   1 -
>>  drivers/memory/tegra/Makefile  |   1 +
>>  drivers/memory/tegra/mc.c  | 184 +++--
>>  drivers/memory/tegra/mc.h  |  10 ++
>>  drivers/memory/tegra/tegra20.c |  72 
>>  drivers/memory/tegra20-mc.c| 254 
>> -
>>  include/soc/tegra/mc.h |   4 +-
>>  8 files changed, 211 insertions(+), 325 deletions(-)
>>  create mode 100644 drivers/memory/tegra/tegra20.c
>>  delete mode 100644 drivers/memory/tegra20-mc.c
> 
> I generally like the idea of unifying the drivers, but I think this case
> is somewhat borderline because the changes don't come naturally. That is
> the parameterizations here seem overly heavy with a lot of special cases
> for Tegra20. To me that indicates that Tegra20 is conceptually too much
> apart from Tegra30 and later to make unification reasonable.
> 
> However, I'd still very much like to see them unified, so let's go
> through the remainder in more detail.
> 
>> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
>> index 19a0e83f260d..8d731d6c3e54 100644
>> --- a/drivers/memory/Kconfig
>> +++ b/drivers/memory/Kconfig
>> @@ -104,16 +104,6 @@ config MVEBU_DEVBUS
>>Armada 370 and Armada XP. This controller allows to handle flash
>>devices such as NOR, NAND, SRAM, and FPGA.
>>  
>> -config TEGRA20_MC
>> -bool "Tegra20 Memory Controller(MC) driver"
>> -default y
>> -depends on ARCH_TEGRA_2x_SOC
>> -help
>> -  This driver is for the Memory Controller(MC) module available
>> -  in Tegra20 SoCs, mainly for a address translation fault
>> -  analysis, especially for IOMMU/GART(Graphics Address
>> -  Relocation Table) module.
>> -
>>  config FSL_CORENET_CF
>>  tristate "Freescale CoreNet Error Reporting"
>>  depends on FSL_SOC_BOOKE
>> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
>> index 66f55240830e..a01ab3e22f94 100644
>> --- a/drivers/memory/Makefile
>> +++ b/drivers/memory/Makefile
>> @@ -16,7 +16,6 @@ obj-$(CONFIG_OMAP_GPMC)+= omap-gpmc.o
>>  obj-$(CONFIG_FSL_CORENET_CF)+= fsl-corenet-cf.o
>>  obj-$(CONFIG_FSL_IFC)   += fsl_ifc.o
>>  obj-$(CONFIG_MVEBU_DEVBUS)  += mvebu-devbus.o
>> -obj-$(CONFIG_TEGRA20_MC)+= tegra20-mc.o
>>  obj-$(CONFIG_JZ4780_NEMC)   += jz4780-nemc.o
>>  obj-$(CONFIG_MTK_SMI)   += mtk-smi.o
>>  obj-$(CONFIG_DA8XX_DDRCTL)  += da8xx-ddrctl.o
>> diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
>> index ce87a9470034..94ab16ba075b 100644
>> --- a/drivers/memory/tegra/Makefile
>> +++ b/drivers/memory/tegra/Makefile
>> @@ -1,6 +1,7 @@
>>  # SPDX-License-Identifier: GPL-2.0
>>  tegra-mc-y := mc.o
>>  
>> +tegra-mc-$(CONFIG_ARCH_TEGRA_2x_SOC)  += tegra20.o
>>  tegra-mc-$(CONFIG_ARCH_TEGRA_3x_SOC)  += tegra30.o
>>  tegra-mc-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114.o
>>  tegra-mc-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124.o
>> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
>> index a4803ac192bb..187a9005351b 100644
>> --- a/drivers/memory/tegra/mc.c
>> +++ b/drivers/memory/tegra/mc.c
>> @@ -27,6 +27,7 @@
>>  #define  MC_INT_INVALID_SMMU_PAGE (1 << 10)
>>  #define  MC_INT_ARBITRATION_EMEM (1 << 9)
>>  #define  MC_INT_SECURITY_VIOLATION (1 << 8)
>> +#define  MC_INT_INVALID_GART_PAGE (1 << 7)
>>  #define  MC_INT_DECERR_EMEM (1 << 6)
>>  
>>  #define MC_INTMASK 0x004
>> @@ -53,7 +54,14 @@
>>  #define MC_EMEM_ADR_CFG 0x54
>>  #define MC_EMEM_ADR_CFG_EMEM_NUMDEV BIT(0)
>>  
>> +#define MC_GART_ERROR_REQ   0x30
>> +#define MC_DECERR_EMEM_OTHERS_STATUS0x58
>> +#define MC_SECURITY_VIOLATION_STATUS0x74
>> +
>>  static const struct of_device_id tegra_mc_of_match[] = {
>> +#ifdef CONFIG_ARCH_TEGRA_2x_SOC
>> +{ .compatible = "nvidia,tegra20-mc", .data = _mc_soc },
>> +#endif
>>  #ifdef CONFIG_ARCH_TEGRA_3x_SOC
>>  { .compatible = "nvidia,tegra30-mc", .data = _mc_soc },
>>  #endif
>> @@ -79,6 +87,9 @@ static int tegra_mc_setup_latency_allowance(struct 
>> tegra_mc *mc)
>>  unsigned int i;
>>  u32 value;
>>  
>> +if (mc->soc->tegra20)
>> +return 0;
> 
> Test for feature flags rather than chip generation. This could be
> swapped for:
> 
>   if (mc->soc->supports_latency_allowance)
>   return 0;

I'll try to do it other way in V2, without introducing any new flag at all.

>> +
>>  /* compute the number of MC clock cycles per tick */
>>  tick = mc->tick * 

[PATCH net 0/4] Fixes, cleanup and modernization for 8390 ethernet drivers

2018-02-18 Thread Finn Thain
Changes since v4 of combined patch series:
- Removed redundant and non-portable MACH_IS_MAC tests.
- Added acked-by tags from Geert Uytterhoeven.
- Omitted patches unrelated to 8390 drivers.


Finn Thain (4):
  net/8390: Remove redundant make dependencies
  net/8390: Fix msg_enable patch snafu
  net/mac8390: Convert to nubus_driver
  net/mac8390: Fix log messages

 drivers/net/Space.c   |   3 -
 drivers/net/ethernet/8390/Makefile|   6 +-
 drivers/net/ethernet/8390/ax88796.c   |   3 -
 drivers/net/ethernet/8390/axnet_cs.c  |   2 -
 drivers/net/ethernet/8390/etherh.c|  17 
 drivers/net/ethernet/8390/hydra.c |   4 -
 drivers/net/ethernet/8390/lib8390.c   |   2 +
 drivers/net/ethernet/8390/mac8390.c   | 171 --
 drivers/net/ethernet/8390/mcf8390.c   |   4 -
 drivers/net/ethernet/8390/ne.c|   2 +-
 drivers/net/ethernet/8390/pcnet_cs.c  |   4 -
 drivers/net/ethernet/8390/wd.c|   2 +-
 drivers/net/ethernet/8390/zorro8390.c |   5 -
 include/net/Space.h   |   1 -
 14 files changed, 85 insertions(+), 141 deletions(-)

-- 
2.16.1



Re: [PATCH net 1/4] net/8390: Remove redundant make dependencies

2018-02-18 Thread Greg Ungerer
Hi Finn,

On 19/02/18 12:39, Finn Thain wrote:
> The hydra, zorro8390 and mcf8390 drivers all #include "lib8390.c" and
> have no need for 8390.o. modinfo confirms no dependency on 8390.ko.
> Drop the redundant dependency from the Makefile. objdump confirms
> that this patch has no effect on the module binaries.
> 
> The superfluous additions of 8390.o were introduced in
> commit 644570b83026 ("8390: Move the 8390 related drivers").
> 
> Cc: Greg Ungerer 

Looks right for mcf8390.c.

Acked-by: Greg Ungerer 

Regards
Greg


> Cc: Geert Uytterhoeven 
> Signed-off-by: Finn Thain 
> Acked-by: Geert Uytterhoeven 
> ---
>  drivers/net/ethernet/8390/Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/8390/Makefile 
> b/drivers/net/ethernet/8390/Makefile
> index f975c2fc88a3..1d650e66cc6e 100644
> --- a/drivers/net/ethernet/8390/Makefile
> +++ b/drivers/net/ethernet/8390/Makefile
> @@ -7,8 +7,8 @@ obj-$(CONFIG_MAC8390) += mac8390.o
>  obj-$(CONFIG_APNE) += apne.o 8390.o
>  obj-$(CONFIG_ARM_ETHERH) += etherh.o
>  obj-$(CONFIG_AX88796) += ax88796.o
> -obj-$(CONFIG_HYDRA) += hydra.o 8390.o
> -obj-$(CONFIG_MCF8390) += mcf8390.o 8390.o
> +obj-$(CONFIG_HYDRA) += hydra.o
> +obj-$(CONFIG_MCF8390) += mcf8390.o
>  obj-$(CONFIG_NE2000) += ne.o 8390p.o
>  obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o
>  obj-$(CONFIG_PCMCIA_AXNET) += axnet_cs.o 8390.o
> @@ -16,4 +16,4 @@ obj-$(CONFIG_PCMCIA_PCNET) += pcnet_cs.o 8390.o
>  obj-$(CONFIG_STNIC) += stnic.o 8390.o
>  obj-$(CONFIG_ULTRA) += smc-ultra.o 8390.o
>  obj-$(CONFIG_WD80x3) += wd.o 8390.o
> -obj-$(CONFIG_ZORRO8390) += zorro8390.o 8390.o
> +obj-$(CONFIG_ZORRO8390) += zorro8390.o
> 



Re: [PATCH 06/15] Documentation: devicetree: dma: Add r8a77965 dmac

2018-02-18 Thread Rob Herring
On Thu, Feb 15, 2018 at 04:56:39PM +0100, Simon Horman wrote:
> On Thu, Feb 15, 2018 at 04:39:49PM +0100, Simon Horman wrote:
> > On Tue, Feb 13, 2018 at 10:45:53AM +0100, Jacopo Mondi wrote:
> > > Add documentation for r8a77965 compatible string to rcar-dmac device
> > > tree bindings documentation.
> > > 
> > > Signed-off-by: Jacopo Mondi 
> > 
> > Reviewed-by: Simon Horman 
> 
> Sorry for not noticing this the first time around.
> 
> I think a better subject would be:
> 
> dt-bindings: dmaengine: rcar-dmac: document R8A77964 support

With that,

Reviewed-by: Rob Herring 



Re: [PATCH 04/15] pinctrl: sh-pfc: Initial R-Car M3-N support

2018-02-18 Thread Rob Herring
On Tue, Feb 13, 2018 at 10:45:51AM +0100, Jacopo Mondi wrote:
> Add initial PFC support for R-Car M3-N (r8a77965) SoC.
> No groups or functions defined, just pin and registers enumeration.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../bindings/pinctrl/renesas,pfc-pinctrl.txt   |1 +

Reviewed-by: Rob Herring 

>  drivers/pinctrl/sh-pfc/Kconfig |5 +
>  drivers/pinctrl/sh-pfc/Makefile|1 +
>  drivers/pinctrl/sh-pfc/core.c  |6 +
>  drivers/pinctrl/sh-pfc/pfc-r8a77965.c  | 2728 
> 
>  drivers/pinctrl/sh-pfc/sh_pfc.h|1 +
>  6 files changed, 2742 insertions(+)
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77965.c


Re: [PATCH 2/2] mfd: arizona: Update DT doc to support more standard reset binding

2018-02-18 Thread Rob Herring
On Wed, Feb 14, 2018 at 03:55:12PM +, Charles Keepax wrote:
> Signed-off-by: Charles Keepax 
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index bdd017686ea5..a1557220825e 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -50,7 +50,7 @@ Required properties:
>  
>  Optional properties:
>  
> -  - wlf,reset : GPIO specifier for the GPIO controlling /RESET
> +  - wlf,reset-gpios : GPIO specifier for the GPIO controlling /RESET

Just reset-gpios is widely used, so you can use that and drop the 
vendor.

>  
>- clocks: Should reference the clocks supplied on MCLK1 and MCLK2
>- clock-names: Should contains two strings:
> @@ -70,6 +70,10 @@ Optional properties:
>  Documentation/devicetree/bindings/regulator/regulator.txt
>  (wm5102, wm5110, wm8280, wm8997, wm8998, wm1814)
>  
> +Deprecated properties:
> +
> +  - wlf,reset : GPIO specifier for the GPIO controlling /RESET
> +
>  Also see child specific device properties:
>Regulator - ../regulator/arizona-regulator.txt
>Extcon- ../extcon/extcon-arizona.txt
> -- 
> 2.11.0
> 


Re: [PATCH 1/3] pata_arasan_cf: Delete an error message for a failed memory allocation in arasan_cf_probe()

2018-02-18 Thread Viresh Kumar
On 16-02-18, 16:57, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 16 Feb 2018 16:01:12 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/ata/pata_arasan_cf.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/ata/pata_arasan_cf.c b/drivers/ata/pata_arasan_cf.c
> index b4d54771c9fe..be5fbcedecbf 100644
> --- a/drivers/ata/pata_arasan_cf.c
> +++ b/drivers/ata/pata_arasan_cf.c
> @@ -809,10 +809,8 @@ static int arasan_cf_probe(struct platform_device *pdev)
>   }
>  
>   acdev = devm_kzalloc(>dev, sizeof(*acdev), GFP_KERNEL);
> - if (!acdev) {
> - dev_warn(>dev, "kzalloc fail\n");
> + if (!acdev)
>   return -ENOMEM;
> - }
>  
>   if (pdata)
>   quirk = pdata->quirk;

Acked-by: Viresh Kumar 

-- 
viresh


Send your prices

2018-02-18 Thread MR.UDU ATTAH
-- 
Dear Sir/Madam,

We need your product and price list catalog.
We are urgently in need of your item .
It is meant for purchase in large quantity by our government of Ecowas
Procurement Inquiry.
Terms of Payment: 80% down payment through T.T while remaining 20% by
L/C will be paid before Shipment.

THANKS,
MR. UDU ATTAH
UDU HOLDINGS GHANA.
6 ACCRA GHANA,
GHANA.
Phone : Phone :+233 261 815595.

EMAIL : agddec...@gmail.com


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

2018-02-18 Thread Stephen Rothwell
Hi all,

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

  drivers/gpu/drm/i915/i915_pmu.h

between commit:

  4c83f0a788cc ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")

from Linus' tree and commit:

  109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs")

from the drm 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/gpu/drm/i915/i915_pmu.h
index bb62df15afa4,5a2e013a56bb..
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@@ -96,10 -94,14 +96,18 @@@ struct i915_pmu 
 * struct intel_engine_cs.
 */
struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
 +  /**
 +   * @suspended_jiffies_last: Cached suspend time from PM core.
 +   */
 +  unsigned long suspended_jiffies_last;
+   /**
+* @i915_attr: Memory block holding device attributes.
+*/
+   void *i915_attr;
+   /**
+* @pmu_attr: Memory block holding device attributes.
+*/
+   void *pmu_attr;
  };
  
  #ifdef CONFIG_PERF_EVENTS


pgpJhp83dm_cQ.pgp
Description: OpenPGP digital signature


Re: [PATCH] watchdog: imx2_wdt: allow setting timeout in devicetree

2018-02-18 Thread Rob Herring
On Thu, Feb 08, 2018 at 02:11:08PM +0100, Marcus Folkesson wrote:
> By following best practice described in
> Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set
> timout-sec property in devicetree.
> 
> Signed-off-by: Marcus Folkesson 
> ---
>  Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++
>  drivers/watchdog/imx2_wdt.c| 8 ++--
>  2 files changed, 4 insertions(+), 6 deletions(-)

Reviewed-by: Rob Herring 



Re: [PATCH 1/2] dt-bindings: clocks: add APB RTC gate for SC9860

2018-02-18 Thread Rob Herring
On Fri, Feb 09, 2018 at 05:48:10PM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang 
> 
> Added index of RTC gate clocks which are used by some devices on aon
> area of SC9860, for example the Watchdog timer.
> 
> Signed-off-by: Chunyan Zhang 
> ---
>  include/dt-bindings/clock/sprd,sc9860-clk.h | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 



Re: [PATCH 10/10] dt-bindings: thermal: Remove "cooling-{min|max}-level" properties

2018-02-18 Thread Rob Herring
On Fri, Feb 09, 2018 at 02:28:10PM +0530, Viresh Kumar wrote:
> The "cooling-min-level" and "cooling-max-level" properties are not
> parsed by any part of kernel currently and the max cooling state of a
> CPU cooling device is found by referring to the cpufreq table instead.

What about non-CPU devices? A fan for example.

> 
> Remove the unused bindings.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  Documentation/devicetree/bindings/thermal/thermal.txt | 16 +---
>  1 file changed, 1 insertion(+), 15 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
> b/Documentation/devicetree/bindings/thermal/thermal.txt
> index 1719d47a5e2f..cc553f0952c5 100644
> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -55,8 +55,7 @@ of heat dissipation). For example a fan's cooling states 
> correspond to
>  the different fan speeds possible. Cooling states are referred to by
>  single unsigned integers, where larger numbers mean greater heat
>  dissipation. The precise set of cooling states associated with a device
> -(as referred to by the cooling-min-level and cooling-max-level
> -properties) should be defined in a particular device's binding.
> +should be defined in a particular device's binding.
>  For more examples of cooling devices, refer to the example sections below.
>  
>  Required properties:
> @@ -69,15 +68,6 @@ For more examples of cooling devices, refer to the example 
> sections below.
>   See Cooling device maps section below for more details
>   on how consumers refer to cooling devices.
>  
> -Optional properties:
> -- cooling-min-level: An integer indicating the smallest
> -  Type: unsigned cooling state accepted. Typically 0.
> -  Size: one cell
> -
> -- cooling-max-level: An integer indicating the largest
> -  Type: unsigned cooling state accepted.
> -  Size: one cell
> -
>  * Trip points
>  
>  The trip node is a node to describe a point in the temperature domain
> @@ -226,8 +216,6 @@ cpus {
>   396000  95
>   198000  85
>   >;
> - cooling-min-level = <0>;
> - cooling-max-level = <3>;
>   #cooling-cells = <2>; /* min followed by max */
>   };
>   ...
> @@ -241,8 +229,6 @@ cpus {
>*/
>   fan0: fan@48 {
>   ...
> - cooling-min-level = <0>;
> - cooling-max-level = <9>;
>   #cooling-cells = <2>; /* min followed by max */
>   };
>  };
> -- 
> 2.15.0.194.g9af6a3dea062
> 


Re: [PATCH] scripts: kernel_doc: fixup reporting of function identifiers

2018-02-18 Thread Jonathan Corbet
On Fri, 16 Feb 2018 17:36:07 +0100
Markus Heiser  wrote:

> > So let me channel akpm here and ask: what are the user-visible effects of
> > this problem?  I ask because applying it doesn't make any difference in
> > the "make htmldocs" output here.  So I don't understand why you're
> > wanting to make this change.  
> 
> Use kernel-doc -v and take a look on the info-messages.
> 
> In Documentation/doc-guide/kernel-doc we recommend to use
> 
> /**
>  * foo() - lorem ipsum
> 
> to tag functions, but if you do so, the info message is broken,
> the function name is missed at the end of the message:
> 
>  ../test123.c:2: info: Scanning doc for  

OK, so I guess that message is the only effect of this bug.  Oh well,
I'll go ahead and apply the patch, thanks.

jon


Re: [PATCH v3 2/7] watchdog: sunxi: allow setting timeout in devicetree

2018-02-18 Thread Rob Herring
On Sun, Feb 11, 2018 at 09:08:42PM +0100, Marcus Folkesson wrote:
> watchdog_init_timeout() will allways pick timeout_param since it
> defaults to a valid timeout.
> 
> By following best practice described in
> Documentation/watchdog/watchdog-kernel-api.txt, it also
> let us to set timout-sec property in devicetree.
> 
> Signed-off-by: Marcus Folkesson 
> Reviewed-by: Guenter Roeck 
> ---
>  Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt | 4 
>  drivers/watchdog/sunxi_wdt.c | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 


[PATCH 1/4] ASoC: intel: kbl_da7219_max98357: replace codec to component

2018-02-18 Thread Kuninori Morimoto
From: Kuninori Morimoto 

Now we can replace Codec to Component. Let's do it.

Signed-off-by: Kuninori Morimoto 
---
 sound/soc/intel/boards/kbl_da7219_max98357a.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a.c 
b/sound/soc/intel/boards/kbl_da7219_max98357a.c
index d689124..e84baaf 100644
--- a/sound/soc/intel/boards/kbl_da7219_max98357a.c
+++ b/sound/soc/intel/boards/kbl_da7219_max98357a.c
@@ -168,7 +168,7 @@ static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime 
*rtd,
 static int kabylake_da7219_codec_init(struct snd_soc_pcm_runtime *rtd)
 {
struct kbl_codec_private *ctx = snd_soc_card_get_drvdata(rtd->card);
-   struct snd_soc_codec *codec = rtd->codec;
+   struct snd_soc_component *component = rtd->codec_dai->component;
struct snd_soc_jack *jack;
int ret;
 
@@ -191,7 +191,7 @@ static int kabylake_da7219_codec_init(struct 
snd_soc_pcm_runtime *rtd)
snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);
-   da7219_aad_jack_det(codec, >kabylake_headset);
+   da7219_aad_jack_det(component, >kabylake_headset);
 
ret = snd_soc_dapm_ignore_suspend(>card->dapm, "SoC DMIC");
if (ret)
@@ -522,12 +522,12 @@ static int kabylake_card_late_probe(struct snd_soc_card 
*card)
 {
struct kbl_codec_private *ctx = snd_soc_card_get_drvdata(card);
struct kbl_hdmi_pcm *pcm;
-   struct snd_soc_codec *codec = NULL;
+   struct snd_soc_component *component = NULL;
int err, i = 0;
char jack_name[NAME_SIZE];
 
list_for_each_entry(pcm, >hdmi_pcm_list, head) {
-   codec = pcm->codec_dai->codec;
+   component = pcm->codec_dai->component;
snprintf(jack_name, sizeof(jack_name),
"HDMI/DP, pcm=%d Jack", pcm->device);
err = snd_soc_card_jack_new(card, jack_name,
@@ -546,10 +546,10 @@ static int kabylake_card_late_probe(struct snd_soc_card 
*card)
 
}
 
-   if (!codec)
+   if (!component)
return -EINVAL;
 
-   return hdac_hdmi_jack_port_init(codec, >dapm);
+   return hdac_hdmi_jack_port_init(component, >dapm);
 }
 
 /* kabylake audio machine driver for SPT + DA7219 */
-- 
1.9.1



[PATCH 0/4] ASoC: missing replace codec to component

2018-02-18 Thread Kuninori Morimoto

Hi Mark

These are new added driver on mark/for-next branch,
but based on old "codec" framework.
We want to convert it to component. These patches are do it

Kuninori Morimoto (4):
  ASoC: intel: kbl_da7219_max98357: replace codec to component
  ASoC: amd: acp-da7219-max98357: replace codec to component
  ASoC: ak4458: replace codec to component
  ASoC: ak5558: replace codec to component

 sound/soc/amd/acp-da7219-max98357a.c  |   4 +-
 sound/soc/codecs/ak4458.c | 105 +-
 sound/soc/codecs/ak5558.c |  65 
 sound/soc/intel/boards/kbl_da7219_max98357a.c |  12 +--
 4 files changed, 94 insertions(+), 92 deletions(-)

-- 
1.9.1



Best regards
---
Kuninori Morimoto


Re: [PATCH v3 5/7] watchdog: mtk: allow setting timeout in devicetree

2018-02-18 Thread Guenter Roeck

On 02/18/2018 04:08 PM, Rob Herring wrote:

On Sun, Feb 11, 2018 at 09:08:45PM +0100, Marcus Folkesson wrote:

watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.

By following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt, it also
let us to set timout-sec property in devicetree.


Same problems in this one.



Same answer. In the existing driver;

mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;

Guenter



Signed-off-by: Marcus Folkesson 
Reviewed-by: Guenter Roeck 
---
  Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 4 
  drivers/watchdog/mtk_wdt.c | 2 +-
  2 files changed, 5 insertions(+), 1 deletion(-)






Re: [PATCH] of: Kconfig: OF_OVERLAY, select OF_EARLY_FLATTREE

2018-02-18 Thread Rob Herring
On Sun, Feb 18, 2018 at 6:29 PM,   wrote:
> From: Frank Rowand 
>
> kbuild test robot reported a new warning for a recent patch:
>>> drivers/of/overlay.c:832:2: error: implicit declaration of function 
>>> 'of_fdt_unflatten_tree' [-Werror=implicit-function-declaration]
>  of_fdt_unflatten_tree(new_fdt, NULL, _root);
>
> The cause is that the prototype for of_fdt_unflatten_tree() in
> include/linux/of_fdt.c is guarded by OF_EARLY_FLATTREE.
>
> This was a pre-existing problem for any overlay related caller of
> of_fdt_unflatten_device_tree(), who was then going to pass the
> unflattened tree to of_overlay_apply().  After the patch that triggered
> this warning, all other overlay callers of of_fdt_unflatten_device_tree()
> no longer exist, so adding the select to OF_OVERLAY is a sufficient fix.
>
> To reproduce the warning:
>   Use the .config attached to https://lkml.org/lkml/2018/2/17/268
>   make ARCH=i386 olddefconfig
>   make ARCH=i386 CC=gcc-7 drivers/of/overlay.o
>
> Signed-off-by: Frank Rowand 
> ---
>  drivers/of/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 783e0870bd22..00a6abfaaec7 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -92,6 +92,7 @@ config OF_RESOLVE
>  config OF_OVERLAY
> bool "Device Tree overlays"
> select OF_DYNAMIC
> +   select OF_EARLY_FLATTREE

If we do this, we might as well kill OF_EARLY_FLATTREE. What platform
really boots from not FDT, but uses DT without overlays?

Rob


[PATCH net 3/4] net/mac8390: Convert to nubus_driver

2018-02-18 Thread Finn Thain
This resolves an old bug that constrained this driver to no more than
one card.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/net/Space.c |   3 -
 drivers/net/ethernet/8390/mac8390.c | 139 +---
 include/net/Space.h |   1 -
 3 files changed, 67 insertions(+), 76 deletions(-)

diff --git a/drivers/net/Space.c b/drivers/net/Space.c
index 11fe71278f40..64333ec999ac 100644
--- a/drivers/net/Space.c
+++ b/drivers/net/Space.c
@@ -114,9 +114,6 @@ static struct devprobe2 m68k_probes[] __initdata = {
 #ifdef CONFIG_MVME147_NET  /* MVME147 internal Ethernet */
{mvme147lance_probe, 0},
 #endif
-#ifdef CONFIG_MAC8390   /* NuBus NS8390-based cards */
-   {mac8390_probe, 0},
-#endif
 #ifdef CONFIG_MAC89x0
{mac89x0_probe, 0},
 #endif
diff --git a/drivers/net/ethernet/8390/mac8390.c 
b/drivers/net/ethernet/8390/mac8390.c
index abe50338b9f7..8042dd73eb6a 100644
--- a/drivers/net/ethernet/8390/mac8390.c
+++ b/drivers/net/ethernet/8390/mac8390.c
@@ -123,8 +123,7 @@ enum mac8390_access {
 };
 
 extern int mac8390_memtest(struct net_device *dev);
-static int mac8390_initdev(struct net_device *dev,
-  struct nubus_rsrc *ndev,
+static int mac8390_initdev(struct net_device *dev, struct nubus_board *board,
   enum mac8390_type type);
 
 static int mac8390_open(struct net_device *dev);
@@ -169,7 +168,7 @@ static void slow_sane_block_output(struct net_device *dev, 
int count,
 static void word_memcpy_tocard(unsigned long tp, const void *fp, int count);
 static void word_memcpy_fromcard(void *tp, unsigned long fp, int count);
 
-static enum mac8390_type __init mac8390_ident(struct nubus_rsrc *fres)
+static enum mac8390_type mac8390_ident(struct nubus_rsrc *fres)
 {
switch (fres->dr_sw) {
case NUBUS_DRSW_3COM:
@@ -235,7 +234,7 @@ static enum mac8390_type __init mac8390_ident(struct 
nubus_rsrc *fres)
return MAC8390_NONE;
 }
 
-static enum mac8390_access __init mac8390_testio(volatile unsigned long 
membase)
+static enum mac8390_access mac8390_testio(unsigned long membase)
 {
unsigned long outdata = 0xA5A0B5B0;
unsigned long indata =  0x;
@@ -253,7 +252,7 @@ static enum mac8390_access __init mac8390_testio(volatile 
unsigned long membase)
return ACCESS_UNKNOWN;
 }
 
-static int __init mac8390_memsize(unsigned long membase)
+static int mac8390_memsize(unsigned long membase)
 {
unsigned long flags;
int i, j;
@@ -289,28 +288,28 @@ static int __init mac8390_memsize(unsigned long membase)
return i * 0x1000;
 }
 
-static bool __init mac8390_init(struct net_device *dev,
-   struct nubus_rsrc *ndev,
-   enum mac8390_type cardtype)
+static bool mac8390_rsrc_init(struct net_device *dev,
+ struct nubus_rsrc *fres,
+ enum mac8390_type cardtype)
 {
+   struct nubus_board *board = fres->board;
struct nubus_dir dir;
struct nubus_dirent ent;
int offset;
volatile unsigned short *i;
 
-   dev->irq = SLOT2IRQ(ndev->board->slot);
+   dev->irq = SLOT2IRQ(board->slot);
/* This is getting to be a habit */
-   dev->base_addr = (ndev->board->slot_addr |
- ((ndev->board->slot & 0xf) << 20));
+   dev->base_addr = board->slot_addr | ((board->slot & 0xf) << 20);
 
/*
 * Get some Nubus info - we will trust the card's idea
 * of where its memory and registers are.
 */
 
-   if (nubus_get_func_dir(ndev, ) == -1) {
+   if (nubus_get_func_dir(fres, ) == -1) {
pr_err("%s: Unable to get Nubus functional directory for slot 
%X!\n",
-  dev->name, ndev->board->slot);
+  dev->name, board->slot);
return false;
}
 
@@ -327,7 +326,7 @@ static bool __init mac8390_init(struct net_device *dev,
if (nubus_find_rsrc(, NUBUS_RESID_MINOR_BASEOS,
) == -1) {
pr_err("%s: Memory offset resource for slot %X not 
found!\n",
-  dev->name, ndev->board->slot);
+  dev->name, board->slot);
return false;
}
nubus_get_rsrc_mem(, , 4);
@@ -338,7 +337,7 @@ static bool __init mac8390_init(struct net_device *dev,
if (nubus_find_rsrc(, NUBUS_RESID_MINOR_LENGTH,
) == -1) {
pr_info("%s: Memory length resource for slot %X not 
found, probing\n",
-   dev->name, ndev->board->slot);
+   dev->name, board->slot);
offset = mac8390_memsize(dev->mem_start);
} else {
 

[PATCH net 4/4] net/mac8390: Fix log messages

2018-02-18 Thread Finn Thain
Use dev_foo() to log the slot number instead of the unexpanded "eth%d"
format string.
Disambiguate the two identical "Card type %s is unsupported" messages.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/net/ethernet/8390/mac8390.c | 36 +---
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/8390/mac8390.c 
b/drivers/net/ethernet/8390/mac8390.c
index 8042dd73eb6a..b6d735bf8011 100644
--- a/drivers/net/ethernet/8390/mac8390.c
+++ b/drivers/net/ethernet/8390/mac8390.c
@@ -308,14 +308,14 @@ static bool mac8390_rsrc_init(struct net_device *dev,
 */
 
if (nubus_get_func_dir(fres, ) == -1) {
-   pr_err("%s: Unable to get Nubus functional directory for slot 
%X!\n",
-  dev->name, board->slot);
+   dev_err(>dev,
+   "Unable to get Nubus functional directory\n");
return false;
}
 
/* Get the MAC address */
if (nubus_find_rsrc(, NUBUS_RESID_MAC_ADDRESS, ) == -1) {
-   pr_info("%s: Couldn't get MAC address!\n", dev->name);
+   dev_info(>dev, "MAC address resource not found\n");
return false;
}
 
@@ -325,8 +325,8 @@ static bool mac8390_rsrc_init(struct net_device *dev,
nubus_rewinddir();
if (nubus_find_rsrc(, NUBUS_RESID_MINOR_BASEOS,
) == -1) {
-   pr_err("%s: Memory offset resource for slot %X not 
found!\n",
-  dev->name, board->slot);
+   dev_err(>dev,
+   "Memory offset resource not found\n");
return false;
}
nubus_get_rsrc_mem(, , 4);
@@ -336,8 +336,8 @@ static bool mac8390_rsrc_init(struct net_device *dev,
nubus_rewinddir();
if (nubus_find_rsrc(, NUBUS_RESID_MINOR_LENGTH,
) == -1) {
-   pr_info("%s: Memory length resource for slot %X not 
found, probing\n",
-   dev->name, board->slot);
+   dev_info(>dev,
+"Memory length resource not found, probing\n");
offset = mac8390_memsize(dev->mem_start);
} else {
nubus_get_rsrc_mem(, , 4);
@@ -380,8 +380,8 @@ static bool mac8390_rsrc_init(struct net_device *dev,
break;
 
default:
-   pr_err("Card type %s is unsupported, sorry\n",
-  board->name);
+   dev_err(>dev,
+   "No known base address for card type\n");
return false;
}
}
@@ -533,7 +533,8 @@ static int mac8390_initdev(struct net_device *dev, struct 
nubus_board *board,
case MAC8390_APPLE:
switch (mac8390_testio(dev->mem_start)) {
case ACCESS_UNKNOWN:
-   pr_err("Don't know how to access card memory!\n");
+   dev_err(>dev,
+   "Don't know how to access card memory\n");
return -ENODEV;
 
case ACCESS_16:
@@ -599,21 +600,18 @@ static int mac8390_initdev(struct net_device *dev, struct 
nubus_board *board,
break;
 
default:
-   pr_err("Card type %s is unsupported, sorry\n",
-  board->name);
+   dev_err(>dev, "Unsupported card type\n");
return -ENODEV;
}
 
__NS8390_init(dev, 0);
 
/* Good, done, now spit out some messages */
-   pr_info("%s: %s in slot %X (type %s)\n",
-   dev->name, board->name, board->slot,
-   cardname[type]);
-   pr_info("MAC %pM IRQ %d, %d KB shared memory at %#lx, %d-bit access.\n",
-   dev->dev_addr, dev->irq,
-   (unsigned int)(dev->mem_end - dev->mem_start) >> 10,
-   dev->mem_start, access_bitmode ? 32 : 16);
+   dev_info(>dev, "%s (type %s)\n", board->name, cardname[type]);
+   dev_info(>dev, "MAC %pM, IRQ %d, %d KB shared memory at %#lx, 
%d-bit access.\n",
+dev->dev_addr, dev->irq,
+(unsigned int)(dev->mem_end - dev->mem_start) >> 10,
+dev->mem_start, access_bitmode ? 32 : 16);
return 0;
 }
 
-- 
2.16.1



Re: [PATCH 19/21] regulator: fixed/gpio: Update device tree bindings

2018-02-18 Thread Rob Herring
On Mon, Feb 12, 2018 at 02:17:15PM +0100, Linus Walleij wrote:
> Deprecate the open drain binding for fixed regulator and indicate
> that we prefer this to be passed in the GPIO phandle flags.
> 
> Clarify that the line inversion semantics for fixed and GPIO
> regulators completely overrides the active low flags in the
> phandle flags.
> 
> Unfortunately this can not be changed to prefer that we pass
> the flags in the phandle: the bindings have been specified and
> deployed such that the presence/absence of this flag and only
> that controls the line inversion semantics. The crucial semantic
> is that the absence of the flag means the core will assume
> the line is active low, which in GPIO terms is an exception,
> as GPIO lines are normally assumed to be active high.
> 
> This special device tree semantic cannot be changed without
> introducing a whole new compatible string for the fixed and
> GPIO regulators, so we just contain the situation.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
>  .../devicetree/bindings/regulator/fixed-regulator.txt   | 13 
> +++--
>  .../devicetree/bindings/regulator/gpio-regulator.txt|  4 
>  2 files changed, 15 insertions(+), 2 deletions(-)

Reviewed-by: Rob Herring 



[PATCH net 2/4] net/8390: Fix msg_enable patch snafu

2018-02-18 Thread Finn Thain
The lib8390 module parameter 'msg_enable' doesn't do anything useful:
it causes an ancient version string to be logged.

Remove redundant code that logs the same string.

In ne.c and wd.c, the value of ei_local->msg_enable is used before
being assigned. Use ne_msg_enable and wd_msg_enable, respectively.

Most of the other 8390 drivers never assign ei_local->msg_enable.
Use the 'msg_enable' module parameter from lib8390 as the default
value.

Eliminate the pointless static and local variables.

Clean up an indentation mistake.

All of these issues originated from the same patch.

Cc: Russell King 
Fixes: c45f812f0280 ("8390 : Replace ei_debug with msg_enable/NETIF_MSG_* 
feature")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
Only the mac8390.c and lib8390.c changes have been tested. The other
changes are similar but untested.
---
 drivers/net/ethernet/8390/ax88796.c   |  3 ---
 drivers/net/ethernet/8390/axnet_cs.c  |  2 --
 drivers/net/ethernet/8390/etherh.c| 17 -
 drivers/net/ethernet/8390/hydra.c |  4 
 drivers/net/ethernet/8390/lib8390.c   |  2 ++
 drivers/net/ethernet/8390/mac8390.c   |  8 
 drivers/net/ethernet/8390/mcf8390.c   |  4 
 drivers/net/ethernet/8390/ne.c|  2 +-
 drivers/net/ethernet/8390/pcnet_cs.c  |  4 
 drivers/net/ethernet/8390/wd.c|  2 +-
 drivers/net/ethernet/8390/zorro8390.c |  5 -
 11 files changed, 4 insertions(+), 49 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c 
b/drivers/net/ethernet/8390/ax88796.c
index 245554707163..da61cf3cb3a9 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -77,8 +77,6 @@ static unsigned char version[] = "ax88796.c: Copyright 
2005,2007 Simtec Electron
 
 #define AX_GPOC_PPDSET BIT(6)
 
-static u32 ax_msg_enable;
-
 /* device private data */
 
 struct ax_device {
@@ -747,7 +745,6 @@ static int ax_init_dev(struct net_device *dev)
ei_local->block_output = _block_output;
ei_local->get_8390_hdr = _get_8390_hdr;
ei_local->priv = 0;
-   ei_local->msg_enable = ax_msg_enable;
 
dev->netdev_ops = _netdev_ops;
dev->ethtool_ops = _ethtool_ops;
diff --git a/drivers/net/ethernet/8390/axnet_cs.c 
b/drivers/net/ethernet/8390/axnet_cs.c
index 7bddb8efb6d5..d422a124cd7c 100644
--- a/drivers/net/ethernet/8390/axnet_cs.c
+++ b/drivers/net/ethernet/8390/axnet_cs.c
@@ -104,7 +104,6 @@ static void AX88190_init(struct net_device *dev, int 
startp);
 static int ax_open(struct net_device *dev);
 static int ax_close(struct net_device *dev);
 static irqreturn_t ax_interrupt(int irq, void *dev_id);
-static u32 axnet_msg_enable;
 
 /**/
 
@@ -151,7 +150,6 @@ static int axnet_probe(struct pcmcia_device *link)
return -ENOMEM;
 
 ei_local = netdev_priv(dev);
-ei_local->msg_enable = axnet_msg_enable;
 spin_lock_init(_local->page_lock);
 
 info = PRIV(dev);
diff --git a/drivers/net/ethernet/8390/etherh.c 
b/drivers/net/ethernet/8390/etherh.c
index 11cbf22ad201..32e9627e3880 100644
--- a/drivers/net/ethernet/8390/etherh.c
+++ b/drivers/net/ethernet/8390/etherh.c
@@ -64,8 +64,6 @@ static char version[] =
 
 #include "lib8390.c"
 
-static u32 etherh_msg_enable;
-
 struct etherh_priv {
void __iomem*ioc_fast;
void __iomem*memc;
@@ -501,18 +499,6 @@ etherh_close(struct net_device *dev)
return 0;
 }
 
-/*
- * Initialisation
- */
-
-static void __init etherh_banner(void)
-{
-   static int version_printed;
-
-   if ((etherh_msg_enable & NETIF_MSG_DRV) && (version_printed++ == 0))
-   pr_info("%s", version);
-}
-
 /*
  * Read the ethernet address string from the on board rom.
  * This is an ascii string...
@@ -671,8 +657,6 @@ etherh_probe(struct expansion_card *ec, const struct 
ecard_id *id)
struct etherh_priv *eh;
int ret;
 
-   etherh_banner();
-
ret = ecard_request_resources(ec);
if (ret)
goto out;
@@ -757,7 +741,6 @@ etherh_probe(struct expansion_card *ec, const struct 
ecard_id *id)
ei_local->block_output  = etherh_block_output;
ei_local->get_8390_hdr  = etherh_get_header;
ei_local->interface_num = 0;
-   ei_local->msg_enable = etherh_msg_enable;
 
etherh_reset(dev);
__NS8390_init(dev, 0);
diff --git a/drivers/net/ethernet/8390/hydra.c 
b/drivers/net/ethernet/8390/hydra.c
index 8ae249195301..941754ea78ec 100644
--- a/drivers/net/ethernet/8390/hydra.c
+++ b/drivers/net/ethernet/8390/hydra.c
@@ -66,7 +66,6 @@ static void hydra_block_input(struct net_device *dev, int 
count,
 static void hydra_block_output(struct net_device *dev, int count,
   const unsigned char *buf, int start_page);
 static void hydra_remove_one(struct zorro_dev *z);
-static u32 hydra_msg_enable;
 
 static struct 

Re: [PATCH v3] perf ftrace: Append an EOL when write tracing files

2018-02-18 Thread Du, Changbin
On Mon, Feb 19, 2018 at 10:21:34AM +0900, Namhyung Kim wrote:
> Hello,
> 
> On Wed, Feb 14, 2018 at 10:44:24AM +0800, changbin...@intel.com wrote:
> > From: Changbin Du 
> > 
> > Before this change, the '--graph-funcs', '--nograph-funcs' and
> > '--trace-funcs' options didn't work as expected when the  doesn't
> > exist. Because the kernel side hid possible errors.
> > 
> > $ sudo ./perf ftrace -a --graph-depth 1 --graph-funcs abcdefg
> >  0)   0.140 us|  rcu_all_qs();
> >  3)   0.304 us|  mutex_unlock();
> >  0)   0.153 us|  find_vma();
> >  3)   0.088 us|  __fsnotify_parent();
> >  0)   6.145 us|  handle_mm_fault();
> >  3)   0.089 us|  fsnotify();
> >  3)   0.161 us|  __sb_end_write();
> >  3)   0.710 us|  SyS_close();
> >  3)   7.848 us|  exit_to_usermode_loop();
> > 
> > On above example, I specified function filter 'abcdefg' but all functions
> > are enabled. The expected error is hidden.
> > 
> > The original fix is to make the kernel support '\0' as end of string:
> > https://lkml.org/lkml/2018/1/16/116
> > 
> > But above fix cannot be compatible with old kernels. Then Namhyung Kim
> > suggest adding a space after function name.
> > 
> > This patch will append an '\n' when write tracing file. After this fix,
> > the perf will report correct error state. Also let it print an error if
> > reset_tracing_files() fails.
> > 
> > Cc: Namhyung Kim 
> > Signed-off-by: Changbin Du 
> > 
> > ---
> > v3: Took Kim's suggestion that add a space after function name.
> > v2: Rebase.
> > ---
> >  tools/perf/builtin-ftrace.c | 15 +--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
> > index 25a42ac..9ffd748 100644
> > --- a/tools/perf/builtin-ftrace.c
> > +++ b/tools/perf/builtin-ftrace.c
> > @@ -72,6 +72,7 @@ static int __write_tracing_file(const char *name, const 
> > char *val, bool append)
> > ssize_t size = strlen(val);
> > int flags = O_WRONLY;
> > char errbuf[512];
> > +   char *val_copy;
> >  
> > file = get_tracing_file(name);
> > if (!file) {
> > @@ -91,12 +92,20 @@ static int __write_tracing_file(const char *name, const 
> > char *val, bool append)
> > goto out;
> > }
> >  
> > -   if (write(fd, val, size) == size)
> > +   /*
> > +* Copy the original value and append a '\n'. Without this,
> > +* the kernel can hide possible errors.
> > +*/
> > +   val_copy = strdup(val);
> 
> Please check the return value.
>
Thanks, I will update.
 
> Thanks,
> Namhyung
> 
> 
> > +   val_copy[size] = '\n';
> > +
> > +   if (write(fd, val_copy, size + 1) == size + 1)
> > ret = 0;
> > else
> > pr_debug("write '%s' to tracing/%s failed: %s\n",
> >  val, name, str_error_r(errno, errbuf, sizeof(errbuf)));
> >  
> > +   free(val_copy);
> > close(fd);
> >  out:
> > put_tracing_file(file);
> > @@ -280,8 +289,10 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, 
> > int argc, const char **argv)
> > signal(SIGCHLD, sig_handler);
> > signal(SIGPIPE, sig_handler);
> >  
> > -   if (reset_tracing_files(ftrace) < 0)
> > +   if (reset_tracing_files(ftrace) < 0) {
> > +   pr_err("failed to reset ftrace\n");
> > goto out;
> > +   }
> >  
> > /* reset ftrace buffer */
> > if (write_tracing_file("trace", "0") < 0)
> > -- 
> > 2.7.4
> > 

-- 
Thanks,
Changbin Du


[PATCH net 1/4] net/8390: Remove redundant make dependencies

2018-02-18 Thread Finn Thain
The hydra, zorro8390 and mcf8390 drivers all #include "lib8390.c" and
have no need for 8390.o. modinfo confirms no dependency on 8390.ko.
Drop the redundant dependency from the Makefile. objdump confirms
that this patch has no effect on the module binaries.

The superfluous additions of 8390.o were introduced in
commit 644570b83026 ("8390: Move the 8390 related drivers").

Cc: Greg Ungerer 
Cc: Geert Uytterhoeven 
Signed-off-by: Finn Thain 
Acked-by: Geert Uytterhoeven 
---
 drivers/net/ethernet/8390/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/8390/Makefile 
b/drivers/net/ethernet/8390/Makefile
index f975c2fc88a3..1d650e66cc6e 100644
--- a/drivers/net/ethernet/8390/Makefile
+++ b/drivers/net/ethernet/8390/Makefile
@@ -7,8 +7,8 @@ obj-$(CONFIG_MAC8390) += mac8390.o
 obj-$(CONFIG_APNE) += apne.o 8390.o
 obj-$(CONFIG_ARM_ETHERH) += etherh.o
 obj-$(CONFIG_AX88796) += ax88796.o
-obj-$(CONFIG_HYDRA) += hydra.o 8390.o
-obj-$(CONFIG_MCF8390) += mcf8390.o 8390.o
+obj-$(CONFIG_HYDRA) += hydra.o
+obj-$(CONFIG_MCF8390) += mcf8390.o
 obj-$(CONFIG_NE2000) += ne.o 8390p.o
 obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o
 obj-$(CONFIG_PCMCIA_AXNET) += axnet_cs.o 8390.o
@@ -16,4 +16,4 @@ obj-$(CONFIG_PCMCIA_PCNET) += pcnet_cs.o 8390.o
 obj-$(CONFIG_STNIC) += stnic.o 8390.o
 obj-$(CONFIG_ULTRA) += smc-ultra.o 8390.o
 obj-$(CONFIG_WD80x3) += wd.o 8390.o
-obj-$(CONFIG_ZORRO8390) += zorro8390.o 8390.o
+obj-$(CONFIG_ZORRO8390) += zorro8390.o
-- 
2.16.1



Re: [PATCH] cpufreq: s3c24xx: Delete an error message for a failed memory allocation in two functions

2018-02-18 Thread Viresh Kumar
On 15-02-18, 17:40, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 15 Feb 2018 17:28:40 +0100
> 
> Omit an extra message for a memory allocation failure in these functions.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/cpufreq/s3c24xx-cpufreq.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c 
> b/drivers/cpufreq/s3c24xx-cpufreq.c
> index 7b596fa38ad2..024afd0b9458 100644
> --- a/drivers/cpufreq/s3c24xx-cpufreq.c
> +++ b/drivers/cpufreq/s3c24xx-cpufreq.c
> @@ -473,10 +473,8 @@ int __init s3c_cpufreq_setboard(struct s3c_cpufreq_board 
> *board)
>* initdata. */
>  
>   ours = kzalloc(sizeof(*ours), GFP_KERNEL);
> - if (ours == NULL) {
> - pr_err("%s: no memory\n", __func__);
> + if (!ours)
>   return -ENOMEM;
> - }
>  
>   *ours = *board;
>   cpu_cur.board = ours;
> @@ -562,10 +560,8 @@ static int s3c_cpufreq_build_freq(void)
>   size++;
>  
>   ftab = kzalloc(sizeof(*ftab) * size, GFP_KERNEL);
> - if (!ftab) {
> - pr_err("%s: no memory for tables\n", __func__);
> + if (!ftab)
>   return -ENOMEM;
> - }
>  
>   ftab_size = size;
>  

Acked-by: Viresh Kumar 

-- 
viresh


  1   2   3   4   5   6   >