Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[gengdongjiu]

Hi James,

On 2017/12/7 14:37, gengdongjiu wrote:
>> We need to tackle (1) and (3) separately. For (3) we need some API that lets
>> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't 
>> have
>> a way of migrating pending SError yet... which is where I got stuck last 
>> time I
>> was looking at this.
> I understand you most idea.
> 
> But In the Qemu one signal type can only correspond to one behavior, can not 
> correspond to two behaviors,
> otherwise Qemu will do not know how to do.
> 
> For the Qemu, if it receives the SIGBUS_MCEERR_AR signal, it will populate 
> the CPER
> records and inject a SEA to guest through KVM IOCTL "KVM_SET_ONE_REG"; if 
> receives the SIGBUS_MCEERR_AO
> signal, it will record the CPER and trigger a IRQ to notify guest, as shown 
> below:
> 
> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
> SIGBUS_MCEERR_AO trigger GPIO IRQ.
> 
> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify 
> trigger method, which all
> 
> not involve _trigger_ an SError.
> 
> so there is no chance for Qemu to trigger the SError when gets the 
> SIGBUS_MCEERR_A{O,R}.

As I explained above:

If Qemu received SIGBUS_MCEERR_AR, it will record CPER and trigger Synchronous 
External Abort;
If Qemu received SIGBUS_MCEERR_AO, it will record CPER and trigger GPIO IRQ;
So Qemu does not know when to _trigger_ an SError.

so here I "return a error" to Qemu if ghes_notify_sei() return failure in [1], 
if you opposed KVM "return error",
do you have a better idea about it? thanks

About the way of migrating pending SError, I think it is a separate case, 
because Qemu still does not know
how and when to trigger the SError.

[1]:
static int kvm_handle_guest_sei(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
...
+   case ESR_ELx_AET_UER:   /* The error has not been propagated */
+   /*
+* Userspace only handle the guest SError Interrupt(SEI) if the
+* error has not been propagated
+*/
+   run->exit_reason = KVM_EXIT_EXCEPTION;
+   run->ex.exception = ESR_ELx_EC_SERROR;
+   run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
+   return 0;
...
}

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] drm/print: Unconfuse kerneldoc

[Alex Deucher]

On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter  wrote:
> It thinks we want to document the __printf(2,0) annotion. Not sure we
> want to teach it about all possible gcc-only flags, hence why I opted
> for the cheap trick of just moving it ahead of the kerneldoc.
>
> This is only a problem for static inline functions, since for
> non-inline function the kerneldoc is in the .c file, but the special
> annotations are all in the header.
>
> Cc'ing kernel-doc maintainers as fyi.
>
> Cc: linux-doc@vger.kernel.org
> Cc: Jonathan Corbet 
> Signed-off-by: Daniel Vetter 

Acked-by: Alex Deucher 

> ---
>  include/drm/drm_print.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 5f9932e2246e..2a4a42e59a47 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -80,13 +80,13 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
> va_format *vaf);
>  __printf(2, 3)
>  void drm_printf(struct drm_printer *p, const char *f, ...);
>
> +__printf(2, 0)
>  /**
>   * drm_vprintf - print to a _printer stream
>   * @p: the _printer
>   * @fmt: format string
>   * @va: the va_list
>   */
> -__printf(2, 0)
>  static inline void
>  drm_vprintf(struct drm_printer *p, const char *fmt, va_list *va)
>  {
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Documentation license

[Matthew Wilcox]

I've written a couple of thousand words of documentation for the XArray.
I need to decide how to license it.  There are no SPDX tags in Documentation/
to date, so I have no examples to crib from.

1. How does one add an SPDX tag to an rst file?

2. What license should I use?  I'd like people to be able to produce
   dead tree versions of the documentation, but if they make improvements
   to it, I want to see them.  Something in the CC BY-SA 4.0 vein?

3. Is there a problem with extracting kernel-doc from a GPLv2 licensed
   file and then redistributing the result under CC BY-SA?  They seem to
   have the same broad intent, but lawyers may grumble.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] kbuild,kconfig: generate lexer/parser C files instead of copying _shipped files

[Masahiro Yamada]

2017-12-10 1:02 GMT+09:00 Masahiro Yamada :
> In Linux build system convention, pre-generated files are version-
> controlled with a "_shipped" suffix.  During the kernel building,
> they are simply shipped (copied) removing the suffix.
>
> From users' point of view, this approach can reduce external tool
> dependency for the kernel build,
>
> From developers point of view, it is tedious to manually regenerate
> such artifacts.  In fact, we see several patches to regenerate
> _shipped files.  They are noise commits.
>
> When we update a *.y or *.l file, it would be better to update the
> corresponding _shipped file in the same commit, but it is painful.
> If you use a different version of flex/bison, it will produce lots of
> irrelevant diffs.
>
> We could update _shipped files after adding various changes to the
> real sources, but it is not very nice for a git-bisect'ability.
> In case of a problem, "git bisect" would point to the commit updating
> _shipped files, but the root cause would be in another commit that
> has changed the corresponding .l or .y files.
>
> Some months ago, I sent RFC patches to run flex, bison, and gperf
> during the build.
> https://lkml.org/lkml/2017/8/19/49
>
> Basically Linus agreed this, but he found a problem in gperf, then
> use of gperf in kernel was removed.
>
> It took some months for me to come back.  This time, I installed various
> versions of flex/bison on my machine, and tested them more carefully.
>
> My current motivation is in Kconfig.
> There are several Kconfig patches touching *.y and *.l
> (and Linus suggested another improvement for Kconfig)
> so I want to remove zconf.lex.c_shipped and zconf.tab.c_shipped now.
> Kconfig has no problem for this switch.
>
> dtc and genksyms will be taken care of later because
> both of them are having shift/reduce conflicts now.
> The ambiguous grammar in dtc has been fixed in upstream, but not
> reflected to kernel yet.  We can proceed migration in sub-system base.
>
>
> Masahiro Yamada (3):
>   kbuild: add LEX and YACC variables
>   kbuild: prepare to remove C files pre-generated by flex and bison
>   kconfig: generate lexer and parser during build instead of shipping
>

I did not get any problem report from the 0-day bot.
I assume flex and bison are installed on their machines.


Fixed a typo pointed out by Randy,
then applied to linux-kbuild/kconfig.



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP

[Randy Dunlap]

On 12/14/2017 12:44 PM, Boris Brezillon wrote:
> On Thu, 14 Dec 2017 12:25:14 -0800
> Randy Dunlap  wrote:
> 
>> On 12/14/2017 12:17 PM, Boris Brezillon wrote:
> + events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
> + ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, );
> + if (ret)
> + pr_info("Failed to re-enable H-J");
Not very good info...  
>>> What do you mean? Is it the H-J that bothers you (I can replace it by
>>> 'Hot-Join'), or is it something else?  
>>
>> Who is the message for?  If it's for developers, you could use
>> pr_debug().  If it's for users, it needs more clarity.
> 
> I think it's of interest to anyone including users. If we fail to
> re-enable Hot-Join that means hotplug is no longer working which is
> a bad news.
> 
>>
>> Does it print the source of the message? (module name e.g.)
> 
> I could replace it by
> 
>   dev_err(m->parent, "Failed to re-enable Hot-Join");
> 

Yes, that's a good plan.

Thanks.

> 
> 
>> and yes, Hot-Join would be better IMO.


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings

[Peter Rosin]

On 2017-12-14 16:16, Boris Brezillon wrote:
> +Optional properties
> +---
> +- reg: static address. Only valid is the device has a static address.
> +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> +property depends on the reg property.
> +
> +Example:
> +
> + i3c-master@0d04 {

i3c-master@d04

(same in patch 7/7)

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP

[Boris Brezillon]

On Thu, 14 Dec 2017 12:25:14 -0800
Randy Dunlap  wrote:

> On 12/14/2017 12:17 PM, Boris Brezillon wrote:
> >>> + events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
> >>> + ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, );
> >>> + if (ret)
> >>> + pr_info("Failed to re-enable H-J");
> >>Not very good info...  
> > What do you mean? Is it the H-J that bothers you (I can replace it by
> > 'Hot-Join'), or is it something else?  
> 
> Who is the message for?  If it's for developers, you could use
> pr_debug().  If it's for users, it needs more clarity.

I think it's of interest to anyone including users. If we fail to
re-enable Hot-Join that means hotplug is no longer working which is
a bad news.

> 
> Does it print the source of the message? (module name e.g.)

I could replace it by

dev_err(m->parent, "Failed to re-enable Hot-Join");



> and yes, Hot-Join would be better IMO.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] drm/print: Unconfuse kerneldoc

[Daniel Vetter]

It thinks we want to document the __printf(2,0) annotion. Not sure we
want to teach it about all possible gcc-only flags, hence why I opted
for the cheap trick of just moving it ahead of the kerneldoc.

This is only a problem for static inline functions, since for
non-inline function the kerneldoc is in the .c file, but the special
annotations are all in the header.

Cc'ing kernel-doc maintainers as fyi.

Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet 
Signed-off-by: Daniel Vetter 
---
 include/drm/drm_print.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 5f9932e2246e..2a4a42e59a47 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -80,13 +80,13 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
va_format *vaf);
 __printf(2, 3)
 void drm_printf(struct drm_printer *p, const char *f, ...);
 
+__printf(2, 0)
 /**
  * drm_vprintf - print to a _printer stream
  * @p: the _printer
  * @fmt: format string
  * @va: the va_list
  */
-__printf(2, 0)
 static inline void
 drm_vprintf(struct drm_printer *p, const char *fmt, va_list *va)
 {
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP

[Randy Dunlap]

On 12/14/2017 12:17 PM, Boris Brezillon wrote:
>>> +   events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
>>> +   ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, );
>>> +   if (ret)
>>> +   pr_info("Failed to re-enable H-J");  
>>  Not very good info...
> What do you mean? Is it the H-J that bothers you (I can replace it by
> 'Hot-Join'), or is it something else?

Who is the message for?  If it's for developers, you could use
pr_debug().  If it's for users, it needs more clarity.

Does it print the source of the message? (module name e.g.)
and yes, Hot-Join would be better IMO.

-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP

[Boris Brezillon]

Hi Randy,

On Thu, 14 Dec 2017 11:54:16 -0800
Randy Dunlap  wrote:

> On 12/14/2017 07:16 AM, Boris Brezillon wrote:
> > Add a driver for Cadence I3C master IP.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> > Changes in v2:
> > - Add basic IBI support. Note that the IP is not really reliable with
> >   regards to IBI because you can't extract IBI payloads as soon as you
> >   have more than one IBI waiting in the HW queue. This is something
> >   that will hopefully be addressed in future revisions of this IP
> > - Add a simple xfer queueing mechanism to optimize message queuing.
> > - Fix a few bugs
> > - Add support for Hot Join
> > ---
> >  drivers/i3c/master/Kconfig   |5 +
> >  drivers/i3c/master/Makefile  |1 +
> >  drivers/i3c/master/i3c-master-cdns.c | 1797 
> > ++
> >  3 files changed, 1803 insertions(+)
> >  create mode 100644 drivers/i3c/master/i3c-master-cdns.c
> > 
> > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> > index e69de29bb2d1..56b9a18543b2 100644
> > --- a/drivers/i3c/master/Kconfig
> > +++ b/drivers/i3c/master/Kconfig
> > @@ -0,0 +1,5 @@
> > +config CDNS_I3C_MASTER
> > +   tristate "Cadence I3C master driver"
> > +   depends on I3C
> > +   help
> > + Enable this driver if you want to support Cadence I3C master block.
> > diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> > index e69de29bb2d1..4c4304aa9534 100644
> > --- a/drivers/i3c/master/Makefile
> > +++ b/drivers/i3c/master/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_CDNS_I3C_MASTER)  += i3c-master-cdns.o
> > diff --git a/drivers/i3c/master/i3c-master-cdns.c 
> > b/drivers/i3c/master/i3c-master-cdns.c
> > new file mode 100644
> > index ..3e3ef37c01c2
> > --- /dev/null
> > +++ b/drivers/i3c/master/i3c-master-cdns.c
> > @@ -0,0 +1,1797 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon 
> > + */
> > +  
> 
> Rule #1 from submit-checklist.rst:
> 1) If you use a facility then #include the file that defines/declares
>that facility.  Don't depend on other header files pulling in ones
>that you use.
> 
> 
> #include 
> for BIT(x) and hweight8() and clear_bit() and find_next_bit()
> and hweight32()
> 
> > +#include   
> 
> #include 
> for IS_ERR(), PTR_ERR()
> 
> #include 
> for error codes
> 
> > +#include 
> > +#include   
> 
> #include 
> for writel()
> 
> > +#include   
> 
> #include 
> for IORESOURCE_MEM
> 
> #include 
> for DIV_ROUND_UP()
> 
> #include 
> for list() macros and INIT_LIST_HEAD()
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include   
> 
> #include 
> 
> #include 
> for workqueue functions and INIT_WORK()

Will fix that.

> 
> > +
> > +#define DEV_ID 0x0
> > +#define DEV_ID_I3C_MASTER  0x5034  
> 
> [snip]
> 
> 
> 
> > +#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE   0x2
> > +#define I3C_DDR_DATA_WORD_PREAMBLE 0x3
> > +
> > +#define I3C_DDR_PREAMBLE(p)((p) << 18)
> > +
> > +static u32 prepare_ddr_word(u16 payload)
> > +{
> > +   u32 ret;
> > +   u16 pb;
> > +
> > +   ret = (u32)payload << 2;
> > +
> > +   /* Calculate parity. */
> > +   pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^
> > +(payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^
> > +(payload >> 3) ^ (payload >> 1);
> > +   ret |= (pb & 1) << 1;
> > +   pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^
> > +(payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^
> > +(payload >> 2) ^ payload ^ 1;
> > +   ret |= (pb & 1);
> > +
> > +   return ret;
> > +}
> > +
> > +static u32 prepare_ddr_data_word(u16 data, bool first)
> > +{
> > +   return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3);  
> 
> Just defined macros for 2 & 3 above. Use them instead of magic numbers?

Oops, that was my intention, just forgot to use the macros I had
defined.

> 
> > +}
> > +
> > +#define I3C_DDR_READ_CMD   BIT(15)
> > +
> > +static u32 prepare_ddr_cmd_word(u16 cmd)
> > +{
> > +   return prepare_ddr_word(cmd) | I3C_DDR_PREAMBLE(1);
> > +}
> > +
> > +static u32 prepare_ddr_crc_word(u8 crc5)
> > +{
> > +   return (((u32)crc5 & 0x1f) << 9) | (0xc << 14) |
> > +  I3C_DDR_PREAMBLE(1);
> > +}
> > +
> > +static u8 update_crc5(u8 crc5, u16 word)
> > +{
> > +   u8 crc0;
> > +   int i;
> > +
> > +   /*
> > +* crc0 = next_data_bit ^ crc[4]
> > +*1 23   4
> > +* crc[4:0] = { crc[3:2], crc[1]^crc0, crc[0], crc0 }
> > +*/
> > +   for (i = 0; i < 16; ++i) {
> > +   crc0 = ((word >> (15 - i)) ^ (crc5 >> 4)) & 0x1;
> > +   crc5 = ((crc5 << 1) & (0x18 | 0x2)) |
> > +  (((crc5 >> 1) ^ crc0) << 2) | crc0;
> > +   }
> > +
> > +   return crc5 & 0x1F;
> 

Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP

[Randy Dunlap]

On 12/14/2017 07:16 AM, Boris Brezillon wrote:
> Add a driver for Cadence I3C master IP.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - Add basic IBI support. Note that the IP is not really reliable with
>   regards to IBI because you can't extract IBI payloads as soon as you
>   have more than one IBI waiting in the HW queue. This is something
>   that will hopefully be addressed in future revisions of this IP
> - Add a simple xfer queueing mechanism to optimize message queuing.
> - Fix a few bugs
> - Add support for Hot Join
> ---
>  drivers/i3c/master/Kconfig   |5 +
>  drivers/i3c/master/Makefile  |1 +
>  drivers/i3c/master/i3c-master-cdns.c | 1797 
> ++
>  3 files changed, 1803 insertions(+)
>  create mode 100644 drivers/i3c/master/i3c-master-cdns.c
> 
> diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> index e69de29bb2d1..56b9a18543b2 100644
> --- a/drivers/i3c/master/Kconfig
> +++ b/drivers/i3c/master/Kconfig
> @@ -0,0 +1,5 @@
> +config CDNS_I3C_MASTER
> + tristate "Cadence I3C master driver"
> + depends on I3C
> + help
> +   Enable this driver if you want to support Cadence I3C master block.
> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> index e69de29bb2d1..4c4304aa9534 100644
> --- a/drivers/i3c/master/Makefile
> +++ b/drivers/i3c/master/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_CDNS_I3C_MASTER)+= i3c-master-cdns.o
> diff --git a/drivers/i3c/master/i3c-master-cdns.c 
> b/drivers/i3c/master/i3c-master-cdns.c
> new file mode 100644
> index ..3e3ef37c01c2
> --- /dev/null
> +++ b/drivers/i3c/master/i3c-master-cdns.c
> @@ -0,0 +1,1797 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon 
> + */
> +

Rule #1 from submit-checklist.rst:
1) If you use a facility then #include the file that defines/declares
   that facility.  Don't depend on other header files pulling in ones
   that you use.


#include 
for BIT(x) and hweight8() and clear_bit() and find_next_bit()
and hweight32()

> +#include 

#include 
for IS_ERR(), PTR_ERR()

#include 
for error codes

> +#include 
> +#include 

#include 
for writel()

> +#include 

#include 
for IORESOURCE_MEM

#include 
for DIV_ROUND_UP()

#include 
for list() macros and INIT_LIST_HEAD()

> +#include 
> +#include 
> +#include 
> +#include 

#include 

#include 
for workqueue functions and INIT_WORK()

> +
> +#define DEV_ID   0x0
> +#define DEV_ID_I3C_MASTER0x5034

[snip]



> +#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE 0x2
> +#define I3C_DDR_DATA_WORD_PREAMBLE   0x3
> +
> +#define I3C_DDR_PREAMBLE(p)  ((p) << 18)
> +
> +static u32 prepare_ddr_word(u16 payload)
> +{
> + u32 ret;
> + u16 pb;
> +
> + ret = (u32)payload << 2;
> +
> + /* Calculate parity. */
> + pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^
> +  (payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^
> +  (payload >> 3) ^ (payload >> 1);
> + ret |= (pb & 1) << 1;
> + pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^
> +  (payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^
> +  (payload >> 2) ^ payload ^ 1;
> + ret |= (pb & 1);
> +
> + return ret;
> +}
> +
> +static u32 prepare_ddr_data_word(u16 data, bool first)
> +{
> + return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3);

Just defined macros for 2 & 3 above. Use them instead of magic numbers?

> +}
> +
> +#define I3C_DDR_READ_CMD BIT(15)
> +
> +static u32 prepare_ddr_cmd_word(u16 cmd)
> +{
> + return prepare_ddr_word(cmd) | I3C_DDR_PREAMBLE(1);
> +}
> +
> +static u32 prepare_ddr_crc_word(u8 crc5)
> +{
> + return (((u32)crc5 & 0x1f) << 9) | (0xc << 14) |
> +I3C_DDR_PREAMBLE(1);
> +}
> +
> +static u8 update_crc5(u8 crc5, u16 word)
> +{
> + u8 crc0;
> + int i;
> +
> + /*
> +  * crc0 = next_data_bit ^ crc[4]
> +  *1 23   4
> +  * crc[4:0] = { crc[3:2], crc[1]^crc0, crc[0], crc0 }
> +  */
> + for (i = 0; i < 16; ++i) {
> + crc0 = ((word >> (15 - i)) ^ (crc5 >> 4)) & 0x1;
> + crc5 = ((crc5 << 1) & (0x18 | 0x2)) |
> +(((crc5 >> 1) ^ crc0) << 2) | crc0;
> + }
> +
> + return crc5 & 0x1F;
> +}
> +

[snip]



> +static int cdns_i3c_master_do_daa_locked(struct cdns_i3c_master *master)
> +{
> + unsigned long i3c_lim_period, pres_step, i3c_scl_lim;
> + struct i3c_device_info devinfo;
> + struct i3c_device *i3cdev;
> + u32 prescl1, ctrl, devs;
> + int ret, slot, ncycles;
> +
> + ret = i3c_master_entdaa_locked(>base);
> + if (ret)
> + return ret;
> +
> + /* Now, add discovered devices to the bus. */
> +  

Re: device attribute documentation

[Greg KH]

On Thu, Dec 14, 2017 at 10:09:44AM -0700, Jonathan Corbet wrote:
> On Thu, 14 Dec 2017 15:30:13 +0100 (CET)
> Julia Lawall  wrote:
> 
> [CC += Greg in case he disagrees]
> 
> > My intern, Aishwarya Pant, is looking into how to improve the
> > documentation of device attributes.  She collected a list of attirbutes
> > that are not represented anywhere under Documentation/ABI, but soeof these
> > seem to be represented elsewhere, for examples:
> > 
> > Documentation/hwmon/sht3x:
> > 
> > sysfs-Interface
> > ---
> > 
> > temp1_input:temperature input
> > humidity1_input:humidity input
> > temp1_max:  temperature max value
> > ...
> > 
> > This is not in the ABI subdirectory and is not in the format used there.
> > Would it be useful to move the information there and fill in the missing
> > parts, or is it good enough as is?
> 
> This seems like a useful exercise and yes, that does seem to me like
> information that should be kept in the ABI directory with the rest.

No objection from me, this would be great to have!

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 08/13] regmap: add SLIMbus support

[Mark Brown]

On Wed, Dec 13, 2017 at 10:25:37AM +0100, Greg Kroah-Hartman wrote:

> Mark, can I get an Ack for this patch so I can take it through my tree
> with the other patches in this series?

I just gave a reviewed-by to the whole series.  Might still make sense
for me to do this one patch, let me know if you (or Takashi) doesn't
take this and I can apply.


signature.asc
Description: PGP signature

Re: [PATCH v10 00/13] Introduce framework for SLIMbus device driver

[Mark Brown]

On Mon, Dec 11, 2017 at 11:42:54PM +, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla 
> 
> SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> developed by MIPI (Mobile Industry Processor Interface) alliance.
> SLIMbus is a 2-wire implementation, which is used to communicate with
> peripheral components like audio-codec.

Reviwed-by: Mark Brown 

This all looks pretty good to me, I might've missed some stuff as this
is a fairly large series but I can't see there would be anything major
and re-reading it again definitely isn't going to help with that so
let's get it merged!


signature.asc
Description: PGP signature

Re: device attribute documentation

[Julia Lawall]

On Thu, 14 Dec 2017, Jonathan Corbet wrote:

> On Thu, 14 Dec 2017 15:30:13 +0100 (CET)
> Julia Lawall  wrote:
>
> [CC += Greg in case he disagrees]
>
> > My intern, Aishwarya Pant, is looking into how to improve the
> > documentation of device attributes.  She collected a list of attirbutes
> > that are not represented anywhere under Documentation/ABI, but soeof these
> > seem to be represented elsewhere, for examples:
> >
> > Documentation/hwmon/sht3x:
> >
> > sysfs-Interface
> > ---
> >
> > temp1_input:temperature input
> > humidity1_input:humidity input
> > temp1_max:  temperature max value
> > ...
> >
> > This is not in the ABI subdirectory and is not in the format used there.
> > Would it be useful to move the information there and fill in the missing
> > parts, or is it good enough as is?
>
> This seems like a useful exercise and yes, that does seem to me like
> information that should be kept in the ABI directory with the rest.

Thanks!

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: device attribute documentation

[Jonathan Corbet]

On Thu, 14 Dec 2017 15:30:13 +0100 (CET)
Julia Lawall  wrote:

[CC += Greg in case he disagrees]

> My intern, Aishwarya Pant, is looking into how to improve the
> documentation of device attributes.  She collected a list of attirbutes
> that are not represented anywhere under Documentation/ABI, but soeof these
> seem to be represented elsewhere, for examples:
> 
> Documentation/hwmon/sht3x:
> 
> sysfs-Interface
> ---
> 
> temp1_input:temperature input
> humidity1_input:humidity input
> temp1_max:  temperature max value
> ...
> 
> This is not in the ABI subdirectory and is not in the format used there.
> Would it be useful to move the information there and fill in the missing
> parts, or is it good enough as is?

This seems like a useful exercise and yes, that does seem to me like
information that should be kept in the ABI directory with the rest.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings

[Geert Uytterhoeven]

Hi Boris,

On Thu, Dec 14, 2017 at 4:16 PM, Boris Brezillon
 wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Signed-off-by: Boris Brezillon 

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> @@ -0,0 +1,128 @@
> +Generic device tree bindings for I3C busses
> +===
> +
> +This document describes generic bindings that should be used to describe I3C
> +busses in a device tree.
> +
> +Required properties
> +---
> +
> +- #address-cells  - should be <1>. Read more about addresses below.
> +- #size-cells - should be <0>.
> +- compatible  - name of I3C bus controller following generic names
> +   recommended practice.
> +
> +For other required properties e.g. to describe register sets,
> +clocks, etc. check the binding documentation of the specific driver.
> +
> +Optional properties
> +---
> +
> +These properties may not be supported by all I3C master drivers. Each I3C
> +master bindings should specify which of them are supported.
> +
> +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> +transfers. When undefined the core set it to 12.5MHz.

sets

> +
> +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> +transfers. When undefined, the core looks at LVR values

LVR (Legacy I2C Virtual Register)

> +of I2C devices described in the device tree to determine
> +the maximum I2C frequency.
> +
> +I2C devices
> +===
> +
> +Each I2C device connected to the bus should be described in a subnode with
> +the following properties:

This colon looks a bit funny here, as below is a sentence, not a list.

> +
> +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> +valid here.

Perhaps rewrite as:

  Each I2C device connected to the bus should be described in a subnode with
  properties.  All properties described in
  Documentation/devicetree/bindings/i2c/i2c.txt are valid here, but several
  new properties have been added.

> +
> +New required properties:
> +
> +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
> +  describing device capabilities as described in the I3C
> +  specification.
> +
> +  bit[31:8]: unused
> +  bit[7:5]: I2C device index. Possible values
> +   * 0: I2C device has a 50 ns spike filter
> +   * 1: I2C device does not have a 50 ns spike filter but supports 
> high
> +frequency on SCL
> +   * 2: I2C device does not have a 50 ns spike filter and is not
> +tolerant to high frequencies
> +   * 3-7: reserved
> +
> +  bit[4]: tell whether the device operates in FM or FM+ mode
> +   * 0: FM+ mode
> +   * 1: FM mode

As this is the only reference to "FM", perhaps clarify the acronym, like you
do for DAA below.

> +
> +  bit[3:0]: device type
> +   * 0-15: reserved
> +
> +I3C devices
> +===
> +
> +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> +are thus discoverable. So, by default, I3C devices do not have to be 
> described
> +in the device tree.
> +This being said, one might want to attach extra resources to these devices,
> +and those resources may have to be described in the device tree, which in 
> turn
> +means we have to describe I3C devices.
> +
> +Another use case for describing an I3C device in the device tree is when this
> +I3C device has a static address and we want to assign it a specific dynamic
> +address before the DAA takes place (so that other devices on the bus can't
> +take this dynamic address).
> +
> +Required properties
> +---
> +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
> +  device discovered during DAA with its device tree definition. The
> +  PID is supposed to be unique on a given bus, which guarantees a 1:1
> +  match. This property becomes optional if a reg property is defined,
> +  meaning that the device has a static address.
> +
> +Optional properties
> +---
> +- reg: static address. Only valid is the device has a static address.

if


-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body 

Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

[Lorenzo Pieralisi]

On Thu, Dec 14, 2017 at 08:08:08AM -0600, Timur Tabi wrote:
> On 12/14/17 4:30 AM, Lorenzo Pieralisi wrote:
> >>I didn't want to put any ACPI code in amba-pl011.c, so putting it in spcr.c
> >>made the most sense.  I agree the global variable is ugly.  If you have a
> >>better idea, I'm all ears.
> 
> >I told you my idea. It could have been made easier by reusing the
> >ACPI_DECLARE_PROBE_ENTRY() mechanism.
> 
> Sorry, I don't mean to be difficult, but when did you tell *me* this idea of
> yours?  I don't see any email from you to me that mentions

I said that IMO it would have been better if the quirk was managed in
amba-pl011.c - you had your reasons not to do it, end of the story.

> ACPI_DECLARE_PROBE_ENTRY().  I've never even heard of that macro before.
> Please note that I'm not the original author of this code.

It is what it is, let's move on, we will keep this in mind if a similar
quirk is required.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/7] i3c: Add sysfs ABI spec

[Boris Brezillon]

Document sysfs files/directories/symlinks exposed by the I3C subsystem.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- new patch
---
 Documentation/ABI/testing/sysfs-bus-i3c | 95 +
 1 file changed, 95 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c

diff --git a/Documentation/ABI/testing/sysfs-bus-i3c 
b/Documentation/ABI/testing/sysfs-bus-i3c
new file mode 100644
index ..5e88cc093e0e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i3c
@@ -0,0 +1,95 @@
+What:  /sys/bus/i3c/devices/i3c-
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   An I3C bus. This directory will contain one sub-directory per
+   I3C device present on the bus.
+
+What:  /sys/bus/i3c/devices/i3c-/current_master
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   Expose the master that owns the bus (-) at
+   the time this file is read. Note that bus ownership can change
+   overtime, so there's no guarantee that when the read() call
+   returns, the value returned is still valid.
+
+What:  /sys/bus/i3c/devices/i3c-/mode
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   I3C bus mode. Can be "pure", "mixed-fast" or "mixed-slow". See
+   the I3C specification for a detailed description of what each
+   of these modes implies.
+
+What:  /sys/bus/i3c/devices/i3c-/i3c_scl_frequency
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   The frequency (expressed in Hz) of the SCL signal when
+   operating in I3C SDR mode.
+
+What:  /sys/bus/i3c/devices/i3c-/i2c_scl_frequency
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   The frequency (expressed in Hz) of the SCL signal when
+   operating in I2C mode.
+
+What:  /sys/bus/i3c/devices/i3c-/-
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   An I3C device present on I3C bus identified by . Note
+   that all devices are represented including the master driving
+   the bus.
+
+What:  /sys/bus/i3c/devices/i3c-/-/address
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   Dynamic address assigned to device -. This
+   address may change if the bus is re-initialized.
+
+What:  /sys/bus/i3c/devices/i3c-/-/bcr
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   BCR stands for Bus Characteristics Register and express the
+   device capabilities in term of speed, maximum read/write
+   length, etc. See the I3C specification for more details.
+
+What:  /sys/bus/i3c/devices/i3c-/-/dcr
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   DCR stands for Device Characteristics Register and express the
+   device capabilities in term of exposed features. See the I3C
+   specification for more details.
+
+What:  /sys/bus/i3c/devices/i3c-/-/pid
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   PID stands for Provisional ID and is used to uniquely identify
+   a device on a bus. This PID contains information about the
+   vendor, the part and an instance ID so that several devices of
+   the same type can be connected on the same bus.
+   See the I3C specification for more details.
+
+What:  /sys/bus/i3c/devices/i3c-/-/hdrcap
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   Expose the HDR (High Data Rate) capabilities of a device.
+   Returns a list of supported HDR mode, each element is separated
+   by space. Modes can be "hdr-ddr", "hdr-tsp" and "hdr-tsl".
+   See the I3C specification for more details about these HDR
+   modes.
+
+What:  /sys/bus/i3c/devices/-
+KernelVersion:  4.16
+Contact:   linux-...@vger.kernel.org
+Description:
+   These directories are just symbolic links to
+   /sys/bus/i3c/devices/i3c-/-.
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/7] docs: driver-api: Add I3C documentation

[Boris Brezillon]

Add the I3C documentation describing the protocol, the master driver API
and the device driver API.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- Moved out of patch "i3c: Add core I3C infrastructure"
- Add link to the I3C spec
- Move rst files in Documentation/driver-api/i3c/
---
 Documentation/driver-api/i3c/conf.py   |  10 +
 Documentation/driver-api/i3c/device-driver-api.rst |   7 +
 Documentation/driver-api/i3c/index.rst |   9 +
 Documentation/driver-api/i3c/master-driver-api.rst |   8 +
 Documentation/driver-api/i3c/protocol.rst  | 201 +
 Documentation/driver-api/index.rst |   1 +
 6 files changed, 236 insertions(+)
 create mode 100644 Documentation/driver-api/i3c/conf.py
 create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
 create mode 100644 Documentation/driver-api/i3c/index.rst
 create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
 create mode 100644 Documentation/driver-api/i3c/protocol.rst

diff --git a/Documentation/driver-api/i3c/conf.py 
b/Documentation/driver-api/i3c/conf.py
new file mode 100644
index ..5a20832d59a7
--- /dev/null
+++ b/Documentation/driver-api/i3c/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "Linux I3C Subsystem"
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'i3c.tex', project,
+ 'The kernel development community', 'manual'),
+]
diff --git a/Documentation/driver-api/i3c/device-driver-api.rst 
b/Documentation/driver-api/i3c/device-driver-api.rst
new file mode 100644
index ..63c843f148a6
--- /dev/null
+++ b/Documentation/driver-api/i3c/device-driver-api.rst
@@ -0,0 +1,7 @@
+=
+I3C device driver API
+=
+
+.. kernel-doc:: include/linux/i3c/device.h
+
+.. kernel-doc:: drivers/i3c/device.c
diff --git a/Documentation/driver-api/i3c/index.rst 
b/Documentation/driver-api/i3c/index.rst
new file mode 100644
index ..9c439220439d
--- /dev/null
+++ b/Documentation/driver-api/i3c/index.rst
@@ -0,0 +1,9 @@
+=
+I3C subsystem
+=
+
+.. toctree::
+
+   protocol
+   device-driver-api
+   master-driver-api
diff --git a/Documentation/driver-api/i3c/master-driver-api.rst 
b/Documentation/driver-api/i3c/master-driver-api.rst
new file mode 100644
index ..017e7711cdf7
--- /dev/null
+++ b/Documentation/driver-api/i3c/master-driver-api.rst
@@ -0,0 +1,8 @@
+
+I3C master controller driver API
+
+
+.. kernel-doc:: drivers/i3c/master.c
+
+.. kernel-doc:: include/linux/i3c/master.h
+
diff --git a/Documentation/driver-api/i3c/protocol.rst 
b/Documentation/driver-api/i3c/protocol.rst
new file mode 100644
index ..891c4f50c472
--- /dev/null
+++ b/Documentation/driver-api/i3c/protocol.rst
@@ -0,0 +1,201 @@
+
+I3C protocol
+
+
+Disclaimer
+==
+
+This chapter will focus on aspects that matter to software developers. For
+everything hardware related (like how things are transmitted on the bus, how
+collisions are prevented, ...) please have a look at the I3C specification.
+
+This document is just a brief introduction to the I3C protocol and the concepts
+it brings on the table. If you need more information, please refer to the MIPI
+I3C specification (can be downloaded here
+http://resources.mipi.org/mipi-i3c-v1-download).
+
+Introduction
+
+
+The I3C (pronounced 'eye-three-see') is a MIPI standardized protocol designed
+to overcome I2C limitations (limited speed, external signals needed for
+interrupts, no automatic detection of the devices connected to the bus, ...)
+while remaining power-efficient.
+
+I3C Bus
+===
+
+An I3C bus is made of several I3C devices and possibly some I2C devices as
+well, but let's focus on I3C devices for now.
+
+An I3C device on the I3C bus can have one of the following roles:
+
+* Master: the device is driving the bus. It's the one in charge of initiating
+  transactions or deciding who is allowed to talk on the bus (slave generated
+  events are possible in I3C, see below).
+* Slave: the device acts as a slave, and is not able to send frames to another
+  slave on the bus. The device can still send events to the master on
+  its own initiative if the master allowed it.
+
+I3C is a multi-master protocol, so there might be several masters on a bus,
+though only one device can act as a master at a given time. In order to gain
+bus ownership, a master has to follow a specific procedure.
+
+Each device on the I3C bus has to be assigned a dynamic address to be able to
+communicate. Until this is done, the device should only respond to a limited
+set of commands. If it has a static address (also called legacy I2C address),
+the device can reply to I2C transfers.
+
+In addition to these per-device addresses, the protocol defines a broadcast
+address in order to 

[PATCH v2 0/7] Add the I3C subsystem

[Boris Brezillon]

This patch series is a proposal for a new I3C [1] subsystem.

This infrastructure is not complete yet and will be extended over
time.

There are a few design choices that are worth mentioning because they
impact the way I3C device drivers can interact with their devices:

- all functions used to send I3C/I2C frames must be called in
  non-atomic context. Mainly done this way to ease implementation, but
  this is still open to discussion. Please let me know if you think it's
  worth considering an asynchronous model here
- the bus element is a separate object and is not implicitly described
  by the master (as done in I2C). The reason is that I want to be able
  to handle multiple master connected to the same bus and visible to
  Linux.
  In this situation, we should only have one instance of the device and
  not one per master, and sharing the bus object would be part of the
  solution to gracefully handle this case.
  I'm not sure if we will ever need to deal with multiple masters
  controlling the same bus and exposed under Linux, but separating the
  bus and master concept is pretty easy, hence the decision to do it
  now, just in case we need it some day.
  The other benefit of separating the bus and master concepts is that
  master devices appear under the bus directory in sysfs.
- I2C backward compatibility has been designed to be transparent to I2C
  drivers and the I2C subsystem. The I3C master just registers an I2C
  adapter which creates a new I2C bus. I'd say that, from a
  representation PoV it's not ideal because what should appear as a
  single I3C bus exposing I3C and I2C devices here appears as 2
  different busses connected to each other through the parenting (the
  I3C master is the parent of the I2C and I3C busses).
  On the other hand, I don't see a better solution if we want something
  that is not invasive.

Missing features in this preliminary version:
- no support for multi-master and the associated concepts (mastership
  handover, support for secondary masters, ...)
- I2C devices can only be described using DT because this is the only
  use case I have. However, the framework can easily be extended with
  ACPI and board info support
- I3C slave framework. This has been completely omitted, but shouldn't
  have a huge impact on the I3C framework because I3C slaves don't see
  the whole bus, it's only about handling master requests and generating
  IBIs. Some of the struct, constant and enum definitions could be
  shared, but most of the I3C slave framework logic will be different

Main changes between the initial RFC and this v2 are:
- Add a generic infrastructure to support IBIs. It's worth mentioning
  that I tried exposing IBIs as a regular IRQs, but after several
  attempts and a discussion with Mark Zyngier, it appeared that it was
  not really fitting in the Linux IRQ model (the fact that you have
  payload attached to IBIs, the fact that most of the time an IBI will
  generate a transfer on the bus which has to be done in an atomic
  context, ...)
  The counterpart of this decision is the latency induced by the
  workqueue approach, but since I don't have real use cases, I don't
  know if this can be a problem or not. 
- Add helpers to support Hot Join
- Add support for IBIs and Hot Join in Cadence I3C master driver
- Address several issues in how I was using the device model

I'll finish on a good news: this week the MIPI alliance opened the I3C
spec. So everyone can now review the patches (no need to be member of
the MIPI I3C group).
I'll let you find the link in the doc, this way maybe I'll have reviews
on the doc itself :-).

Thanks,

Boris

Boris Brezillon (7):
  i2c: Export of_i2c_get_board_info()
  i3c: Add core I3C infrastructure
  docs: driver-api: Add I3C documentation
  i3c: Add sysfs ABI spec
  dt-bindings: i3c: Document core bindings
  i3c: master: Add driver for Cadence IP
  dt-bindings: i3c: Document Cadence I3C master bindings

 Documentation/ABI/testing/sysfs-bus-i3c|   95 ++
 .../devicetree/bindings/i3c/cdns,i3c-master.txt|   45 +
 Documentation/devicetree/bindings/i3c/i3c.txt  |  128 ++
 Documentation/driver-api/i3c/conf.py   |   10 +
 Documentation/driver-api/i3c/device-driver-api.rst |7 +
 Documentation/driver-api/i3c/index.rst |9 +
 Documentation/driver-api/i3c/master-driver-api.rst |8 +
 Documentation/driver-api/i3c/protocol.rst  |  201 +++
 Documentation/driver-api/index.rst |1 +
 drivers/Kconfig|2 +
 drivers/Makefile   |2 +-
 drivers/i2c/i2c-core-base.c|2 +-
 drivers/i2c/i2c-core-of.c  |   66 +-
 drivers/i3c/Kconfig|   24 +
 drivers/i3c/Makefile   |4 +
 drivers/i3c/core.c |  573 +++
 drivers/i3c/device.c   |  344 

[PATCH v2 7/7] dt-bindings: i3c: Document Cadence I3C master bindings

[Boris Brezillon]

Document Cadence I3C master DT bindings.

Signed-off-by: Boris Brezillon 
---
 .../devicetree/bindings/i3c/cdns,i3c-master.txt| 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt

diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt 
b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
new file mode 100644
index ..f9e4af4ff1c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
@@ -0,0 +1,45 @@
+Bindings for cadence I3C master block
+=
+
+Required properties:
+
+- compatible: shall be "cdns,i3c-master"
+- clocks: shall reference the pclk and sysclk
+- clock-names: shall contain "pclk" and "sysclk"
+- interrupts: the interrupt line connected to this I3C master
+- reg: I3C master registers
+
+Mandatory properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- #address-cells: shall be set to 1
+- #size-cells: shall be set to 0
+
+Optional properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- i2c-scl-frequency
+- i3c-scl-frequency
+
+I3C device connected on the bus follow the generic description (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details).
+
+Example:
+
+   i3c-master@0d04 {
+   compatible = "cdns,i3c-master";
+   clocks = <>, <>;
+   clock-names = "pclk", "sysclk";
+   interrupts = <3 0>;
+   reg = <0x0d04 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   i2c-scl-frequency = <10>;
+
+   nunchuk: nunchuk@52 {
+   compatible = "nintendo,nunchuk";
+   reg = <0x52>;
+   i3c-lvr = <0x10>;
+   };
+   };
+
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/7] i2c: Export of_i2c_get_board_info()

[Boris Brezillon]

I3C busses have to know about all I2C devices connected on the I3C bus
to properly initialize the I3C master, and I2C frames can't be sent on
the bus until this initialization is done.

We can't let the I2C core parse the DT and instantiate I2C devices as
part of its i2c_add_adapter() procedure because, when done this way,
I2C devices are directly registered to the device-model and might be
attached to drivers which could in turn start sending frames on the bus,
which won't work since, as said above, the bus is not yet initialized.

Export of_i2c_register_device() in order to let the I3C core parse the
I2C device nodes by itself and initialize the bus.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- fix memset() call
- rebase on v4.15-rc1
---
 drivers/i2c/i2c-core-base.c |  2 +-
 drivers/i2c/i2c-core-of.c   | 66 ++---
 include/linux/i2c.h | 10 +++
 3 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 706164b4c5be..025df16e64be 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -774,7 +774,7 @@ i2c_new_device(struct i2c_adapter *adap, struct 
i2c_board_info const *info)
client->dev.parent = >adapter->dev;
client->dev.bus = _bus_type;
client->dev.type = _client_type;
-   client->dev.of_node = info->of_node;
+   client->dev.of_node = of_node_get(info->of_node);
client->dev.fwnode = info->fwnode;
 
i2c_dev_set_name(adap, client, info);
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 8d474bb1dc15..7470bc418a3b 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -22,56 +22,66 @@
 
 #include "i2c-core.h"
 
-static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
-struct device_node *node)
+int of_i2c_get_board_info(struct device *dev, struct device_node *node,
+ struct i2c_board_info *info)
 {
-   struct i2c_client *result;
-   struct i2c_board_info info = {};
-   struct dev_archdata dev_ad = {};
-   const __be32 *addr_be;
u32 addr;
-   int len;
+   int ret;
 
-   dev_dbg(>dev, "of_i2c: register %pOF\n", node);
+   memset(info, 0, sizeof(*info));
 
-   if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
-   dev_err(>dev, "of_i2c: modalias failure on %pOF\n",
-   node);
-   return ERR_PTR(-EINVAL);
+   if (of_modalias_node(node, info->type, sizeof(info->type)) < 0) {
+   dev_err(dev, "of_i2c: modalias failure on %pOF\n", node);
+   return -EINVAL;
}
 
-   addr_be = of_get_property(node, "reg", );
-   if (!addr_be || (len < sizeof(*addr_be))) {
-   dev_err(>dev, "of_i2c: invalid reg on %pOF\n", node);
-   return ERR_PTR(-EINVAL);
+   ret = of_property_read_u32(node, "reg", );
+   if (ret) {
+   dev_err(dev, "of_i2c: invalid reg on %pOF\n", node);
+   return ret;
}
 
-   addr = be32_to_cpup(addr_be);
if (addr & I2C_TEN_BIT_ADDRESS) {
addr &= ~I2C_TEN_BIT_ADDRESS;
-   info.flags |= I2C_CLIENT_TEN;
+   info->flags |= I2C_CLIENT_TEN;
}
 
if (addr & I2C_OWN_SLAVE_ADDRESS) {
addr &= ~I2C_OWN_SLAVE_ADDRESS;
-   info.flags |= I2C_CLIENT_SLAVE;
+   info->flags |= I2C_CLIENT_SLAVE;
}
 
-   if (i2c_check_addr_validity(addr, info.flags)) {
-   dev_err(>dev, "of_i2c: invalid addr=%x on %pOF\n",
-   addr, node);
-   return ERR_PTR(-EINVAL);
+   ret = i2c_check_addr_validity(addr, info->flags);
+   if (ret) {
+   dev_err(dev, "of_i2c: invalid addr=%x on %pOF\n", addr, node);
+   return ret;
}
 
-   info.addr = addr;
-   info.of_node = of_node_get(node);
-   info.archdata = _ad;
+   info->addr = addr;
+   info->of_node = node;
 
if (of_property_read_bool(node, "host-notify"))
-   info.flags |= I2C_CLIENT_HOST_NOTIFY;
+   info->flags |= I2C_CLIENT_HOST_NOTIFY;
 
if (of_get_property(node, "wakeup-source", NULL))
-   info.flags |= I2C_CLIENT_WAKE;
+   info->flags |= I2C_CLIENT_WAKE;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_i2c_get_board_info);
+
+static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
+struct device_node *node)
+{
+   struct i2c_client *result;
+   struct i2c_board_info info;
+   int ret;
+
+   dev_dbg(>dev, "of_i2c: register %pOF\n", node);
+
+   ret = of_i2c_get_board_info(>dev, node, );
+   if (ret)
+   return ERR_PTR(ret);
 
result = 

[PATCH 0/6] Fix cdrom autoclose

[Michal Suchanek]

Hello,

there is cdrom autoclose feature that is supposed to close the tray, wait for
the disc to become ready, and then open the device.

This used to work in ancient times. Then in old times there was a hack in
util-linux which worked around the breakage which probably resulted from
switching to scsi emulation.

Currently util-linux maintainer refuses to merge another hack on the basis that
kernel still has the feature so it should be fixed there. Indeed, to implement
this feature effectively from userspace one would need to know when the CD-ROM
is in the "drive becoming ready" state which is knowledge that never leaves the
hardware-specific driver and is passed neither to userspace nor the generic
cdrom driver.

So this patchset fixes the kernel autoclose implementation in cdrom.c and to
do so reports the "drive becoming ready" state from the harware specific
drivers.

Michal Suchanek (6):
  delay: add poll_event_interruptible
  cdrom: factor out common open_for_* code
  cdrom: wait for tray to close
  cdrom: introduce CDS_DRIVE_ERROR
  Documentetion: cdrom: introduce CDS_DRIVE_ERROR
  cdrom: wait for drive to become ready

 Documentation/cdrom/cdrom-standard.tex |   8 ++-
 Documentation/cdrom/ide-cd |   6 ++
 Documentation/ioctl/cdrom.txt  |   1 +
 drivers/block/paride/pcd.c |   2 +-
 drivers/cdrom/cdrom.c  | 124 -
 drivers/cdrom/gdrom.c  |   2 +-
 drivers/ide/ide-cd_ioctl.c |  12 ++--
 drivers/scsi/sr_ioctl.c|   2 +-
 include/linux/delay.h  |  12 
 include/uapi/linux/cdrom.h |   1 +
 10 files changed, 99 insertions(+), 71 deletions(-)

-- 
2.13.6

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/7] dt-bindings: i3c: Document core bindings

[Boris Brezillon]

A new I3C subsystem has been added and a generic description has been
created to represent the I3C bus and the devices connected on it.

Document this generic representation.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- Define how to describe I3C devices in the DT and when it should be
  used. Note that the parsing of I3C devices is not yet implemented in
  the framework. Will be added when someone really needs it.
---
 Documentation/devicetree/bindings/i3c/i3c.txt | 128 ++
 1 file changed, 128 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt

diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt 
b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index ..79a214dee025
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,128 @@
+Generic device tree bindings for I3C busses
+===
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+---
+
+- #address-cells  - should be <1>. Read more about addresses below.
+- #size-cells - should be <0>.
+- compatible  - name of I3C bus controller following generic names
+   recommended practice.
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+
+Optional properties
+---
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
+transfers. When undefined the core set it to 12.5MHz.
+
+- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
+transfers. When undefined, the core looks at LVR values
+of I2C devices described in the device tree to determine
+the maximum I2C frequency.
+
+I2C devices
+===
+
+Each I2C device connected to the bus should be described in a subnode with
+the following properties:
+
+All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here.
+
+New required properties:
+
+- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
+  describing device capabilities as described in the I3C
+  specification.
+
+  bit[31:8]: unused
+  bit[7:5]: I2C device index. Possible values
+   * 0: I2C device has a 50 ns spike filter
+   * 1: I2C device does not have a 50 ns spike filter but supports high
+frequency on SCL
+   * 2: I2C device does not have a 50 ns spike filter and is not
+tolerant to high frequencies
+   * 3-7: reserved
+
+  bit[4]: tell whether the device operates in FM or FM+ mode
+   * 0: FM+ mode
+   * 1: FM mode
+
+  bit[3:0]: device type
+   * 0-15: reserved
+
+I3C devices
+===
+
+All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
+are thus discoverable. So, by default, I3C devices do not have to be described
+in the device tree.
+This being said, one might want to attach extra resources to these devices,
+and those resources may have to be described in the device tree, which in turn
+means we have to describe I3C devices.
+
+Another use case for describing an I3C device in the device tree is when this
+I3C device has a static address and we want to assign it a specific dynamic
+address before the DAA takes place (so that other devices on the bus can't
+take this dynamic address).
+
+Required properties
+---
+- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
+  device discovered during DAA with its device tree definition. The
+  PID is supposed to be unique on a given bus, which guarantees a 1:1
+  match. This property becomes optional if a reg property is defined,
+  meaning that the device has a static address.
+
+Optional properties
+---
+- reg: static address. Only valid is the device has a static address.
+- i3c-dynamic-address: dynamic address to be assigned to this device. This
+  property depends on the reg property.
+
+Example:
+
+   i3c-master@0d04 {
+   compatible = "cdns,i3c-master";
+   clocks = <>, <>;
+   clock-names = "pclk", "sysclk";
+   interrupts = <3 0>;
+   reg = <0x0d04 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   status = "okay";
+   i2c-scl-frequency = <10>;
+
+   /* I2C device. */
+   nunchuk: nunchuk@52 {
+   compatible = 

[PATCH v2 6/7] i3c: master: Add driver for Cadence IP

[Boris Brezillon]

Add a driver for Cadence I3C master IP.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- Add basic IBI support. Note that the IP is not really reliable with
  regards to IBI because you can't extract IBI payloads as soon as you
  have more than one IBI waiting in the HW queue. This is something
  that will hopefully be addressed in future revisions of this IP
- Add a simple xfer queueing mechanism to optimize message queuing.
- Fix a few bugs
- Add support for Hot Join
---
 drivers/i3c/master/Kconfig   |5 +
 drivers/i3c/master/Makefile  |1 +
 drivers/i3c/master/i3c-master-cdns.c | 1797 ++
 3 files changed, 1803 insertions(+)
 create mode 100644 drivers/i3c/master/i3c-master-cdns.c

diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
index e69de29bb2d1..56b9a18543b2 100644
--- a/drivers/i3c/master/Kconfig
+++ b/drivers/i3c/master/Kconfig
@@ -0,0 +1,5 @@
+config CDNS_I3C_MASTER
+   tristate "Cadence I3C master driver"
+   depends on I3C
+   help
+ Enable this driver if you want to support Cadence I3C master block.
diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
index e69de29bb2d1..4c4304aa9534 100644
--- a/drivers/i3c/master/Makefile
+++ b/drivers/i3c/master/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CDNS_I3C_MASTER)  += i3c-master-cdns.o
diff --git a/drivers/i3c/master/i3c-master-cdns.c 
b/drivers/i3c/master/i3c-master-cdns.c
new file mode 100644
index ..3e3ef37c01c2
--- /dev/null
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -0,0 +1,1797 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEV_ID 0x0
+#define DEV_ID_I3C_MASTER  0x5034
+
+#define CONF_STATUS0   0x4
+#define CONF_STATUS0_ECC_CHK   BIT(28)
+#define CONF_STATUS0_INTEG_CHK BIT(27)
+#define CONF_STATUS0_CSR_DAP_CHK   BIT(26)
+#define CONF_STATUS0_TRANS_TOUT_CHKBIT(25)
+#define CONF_STATUS0_PROT_FAULTS_CHK   BIT(24)
+#define CONF_STATUS0_GPO_NUM(x)(((x) & GENMASK(23, 16)) >> 16)
+#define CONF_STATUS0_GPI_NUM(x)(((x) & GENMASK(15, 8)) >> 8)
+#define CONF_STATUS0_SUPPORTS_DDR  BIT(5)
+#define CONF_STATUS0_SEC_MASTERBIT(4)
+#define CONF_STATUS0_DEVS_NUM(x)   ((x) & GENMASK(3, 0))
+
+#define CONF_STATUS1   0x8
+#define CONF_STATUS1_IBI_HW_RES(x) x) & GENMASK(31, 28)) >> 28) + 1)
+#define CONF_STATUS1_CMD_DEPTH(x)  (4 << (((x) & GENMASK(27, 26)) >> 26))
+#define CONF_STATUS1_SLVDDR_RX_DEPTH(x)(8 << (((x) & GENMASK(25, 21)) 
>> 21))
+#define CONF_STATUS1_SLVDDR_TX_DEPTH(x)(8 << (((x) & GENMASK(20, 16)) 
>> 16))
+#define CONF_STATUS1_IBI_DEPTH(x)  (2 << (((x) & GENMASK(12, 10)) >> 10))
+#define CONF_STATUS1_RX_DEPTH(x)   (8 << (((x) & GENMASK(9, 5)) >> 5))
+#define CONF_STATUS1_TX_DEPTH(x)   (8 << ((x) & GENMASK(4, 0)))
+
+#define REV_ID 0xc
+#define REV_ID_VID(id) (((id) & GENMASK(31, 20)) >> 20)
+#define REV_ID_PID(id) (((id) & GENMASK(19, 8)) >> 8)
+#define REV_ID_REV_MAJOR(id)   (((id) & GENMASK(7, 4)) >> 4)
+#define REV_ID_REV_MINOR(id)   ((id) & GENMASK(3, 0))
+
+#define CTRL   0x10
+#define CTRL_DEV_ENBIT(31)
+#define CTRL_HALT_EN   BIT(30)
+#define CTRL_HJ_DISEC  BIT(8)
+#define CTRL_MST_ACK   BIT(7)
+#define CTRL_HJ_ACKBIT(6)
+#define CTRL_HJ_INIT   BIT(5)
+#define CTRL_MST_INIT  BIT(4)
+#define CTRL_AHDR_OPT  BIT(3)
+#define CTRL_PURE_BUS_MODE 0
+#define CTRL_MIXED_FAST_BUS_MODE   2
+#define CTRL_MIXED_SLOW_BUS_MODE   3
+#define CTRL_BUS_MODE_MASK GENMASK(1, 0)
+
+#define PRESCL_CTRL0   0x14
+#define PRESCL_CTRL0_I2C(x)((x) << 16)
+#define PRESCL_CTRL0_I3C(x)(x)
+#define PRESCL_CTRL0_MAX   GENMASK(9, 0)
+
+#define PRESCL_CTRL1   0x18
+#define PRESCL_CTRL1_PP_LOW_MASK   GENMASK(15, 8)
+#define PRESCL_CTRL1_PP_LOW(x) ((x) << 8)
+#define PRESCL_CTRL1_OD_LOW_MASK   GENMASK(7, 0)
+#define PRESCL_CTRL1_OD_LOW(x) (x)
+
+#define MST_IER0x20
+#define MST_IDR0x24
+#define MST_IMR0x28
+#define MST_ICR0x2c
+#define MST_ISR0x30
+#define MST_INT_M0_ERR BIT(28)
+#define MST_INT_RX_THR BIT(24)
+#define MST_INT_TX_THR BIT(23)
+#define 

Re: [PATCH v10 00/13] Introduce framework for SLIMbus device driver

[Srinivas Kandagatla]

On 13/12/17 09:25, Greg Kroah-Hartman wrote:

On Mon, Dec 11, 2017 at 11:42:54PM +, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 

SLIMbus (Serial Low Power Interchip Media Bus) is a specification
developed by MIPI (Mobile Industry Processor Interface) alliance.
SLIMbus is a 2-wire implementation, which is used to communicate with
peripheral components like audio-codec.
SLIMbus uses Time-Division-Multiplexing to accommodate multiple data
channels, and control channel. Control channel has messages to do
device-enumeration, messages to send/receive control-data to/from
SLIMbus devices, messages for port/channel management, and messages to
do bandwidth allocation.
Framework is introduced to support  multiple instances of the bus
(1 controller per bus), and multiple slave devices per controller.
SPI and I2C frameworks, and comments from last time when I submitted
the patches were referred-to while working on this framework.

These patchsets introduce device-management, OF helpers, and messaging
APIs, controller driver for Qualcomm's SLIMbus controller, and
clock-pause feature for entering/exiting low-power mode for SLIMbus.
Framework patches to do channel, port and bandwidth
management are work-in-progress and will be sent out once these
initial patches are accepted.

These patchsets were tested on IFC6410 board with Qualcomm APQ8064
processor using the controller driver, and a WCD9310 codec.

v9: https://lkml.org/lkml/2017/12/7/289

Changes from v9 to v10:
* Added kernel-doc reference into slimbus driver api doc suggested by
  Jonathan Corbet


These all look good to me.  I can take this through my tree if I get the
ack from Mark for the regmap changes.



Greg, Can you please pick up the series except the regmap patch, Mark 
said that he will apply it separately.



Thanks
srini

thanks,

greg k-h


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH v10 08/13] regmap: add SLIMbus support

[Srinivas Kandagatla]

On 14/12/17 08:19, Takashi Iwai wrote:

On Thu, 14 Dec 2017 06:17:39 +0100,
Vinod Koul wrote:


On Wed, Dec 13, 2017 at 04:06:11PM +, Mark Brown wrote:

On Mon, Dec 11, 2017 at 11:43:02PM +, srinivas.kandaga...@linaro.org wrote:



Mark, can I get an Ack for this patch so I can take it through my tree
with the other patches in this series?


I'm actually not seeing a direct dependency here (there's a depends in
place stopping the regmap code building if the Slimbus core isn't
enabled) so if you want you can go ahead and apply the main stuff and I
can apply the regmap change separately, it'll avoid Makefile/Kconfig
conflicts anyway.


+ Takashi

FWIW, since this is another MIPI Audio specfic bus, would it make sense for
this series to go thru sound/ tree? I have discussed with Takashi and Greg
for soundwire and we are taking sound path.

Would that be okay here too? Either ways I dont mind :)


Me too, I don't mind who takes what.
Just let me know.



It was implied early that Greg would pick up the main stuff and Mark can 
apply regmap separately to avoid Makefile/Kconfig conflicts.


Lets keep it that way to avoid anymore confusion.

Thanks,
srini




thanks,

Takashi


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

On Tue, Dec 12, 2017 at 03:07:50PM +0100, Pavel Machek wrote:
> On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote:
> > Intel(R) SGX is a set of CPU instructions that can be used by applications 
> > to
> > set aside private regions of code and data. The code outside the enclave is
> > disallowed to access the memory inside the enclave by the CPU access 
> > control.
> > In a way you can think that SGX provides inverted sandbox. It protects the
> > application from a malicious host.
> 
> Would you list guarantees provided by SGX?
> 
> For example, host can still observe timing of cachelines being
> accessed by "protected" app, right? Can it also introduce bit flips?
> 
>   Pavel

I'll put this in my backlog. Thank you.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

[Lorenzo Pieralisi]

On Wed, Dec 13, 2017 at 03:11:33PM -0600, Timur Tabi wrote:
> On 12/13/2017 06:45 AM, Lorenzo Pieralisi wrote:
> >>+/*
> >>+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> >>+ * occasionally getting stuck as 1. To avoid the potential for a hang, 
> >>check
> >>+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> >>+ * implementations, so only do so if an affected platform is detected in
> >>+ * acpi_parse_spcr().
> >>+ */
> >>+bool qdf2400_e44_present;
> >>+EXPORT_SYMBOL(qdf2400_e44_present);
> >
> >My eyes, this is horrible but it is not introduced by this patch. It
> >would have been much better if:
> >
> >drivers/tty/serial/amba-pl011.c
> >
> >parsed the SPCR table (again) to detect it instead of relying on this
> >horrible exported flag.
> 
> I didn't want to put any ACPI code in amba-pl011.c, so putting it in spcr.c
> made the most sense.  I agree the global variable is ugly.  If you have a
> better idea, I'm all ears.

I told you my idea. It could have been made easier by reusing the
ACPI_DECLARE_PROBE_ENTRY() mechanism.

> If it's any consolation, this erratum affects only 1.x silicon, which is
> technically pre-production (although a lot of people have them).  This
> work-around will eventually be reverted.

The sooner the better.

Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH v10 08/13] regmap: add SLIMbus support

[Takashi Iwai]

On Thu, 14 Dec 2017 06:17:39 +0100,
Vinod Koul wrote:
> 
> On Wed, Dec 13, 2017 at 04:06:11PM +, Mark Brown wrote:
> > > On Mon, Dec 11, 2017 at 11:43:02PM +, srinivas.kandaga...@linaro.org 
> > > wrote:
> > 
> > > Mark, can I get an Ack for this patch so I can take it through my tree
> > > with the other patches in this series?
> > 
> > I'm actually not seeing a direct dependency here (there's a depends in
> > place stopping the regmap code building if the Slimbus core isn't
> > enabled) so if you want you can go ahead and apply the main stuff and I
> > can apply the regmap change separately, it'll avoid Makefile/Kconfig
> > conflicts anyway.
> 
> + Takashi
> 
> FWIW, since this is another MIPI Audio specfic bus, would it make sense for
> this series to go thru sound/ tree? I have discussed with Takashi and Greg
> for soundwire and we are taking sound path.
> 
> Would that be okay here too? Either ways I dont mind :)

Me too, I don't mind who takes what.
Just let me know.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html