All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] goldfish_rtc: Fix non-atomic read behaviour of TIME_LOW/TIME_HIGH
From: Richard Henderson @ 2020-07-18  0:43 UTC (permalink / raw)
  To: Jessica Clarke, qemu-riscv; +Cc: Alistair Francis, Anup Patel, qemu-devel
In-Reply-To: <20200718002027.82300-1-jrtc27@jrtc27.com>

On 7/17/20 5:20 PM, Jessica Clarke wrote:
> The specification says:
> 
>    0x00  TIME_LOW   R: Get current time, then return low-order 32-bits.
>    0x04  TIME_HIGH  R: Return high 32-bits from previous TIME_LOW read.
> 
>    ...
> 
>    To read the value, the kernel must perform an IO_READ(TIME_LOW),
>    which returns an unsigned 32-bit value, before an IO_READ(TIME_HIGH),
>    which returns a signed 32-bit value, corresponding to the higher half
>    of the full value.
> 
> However, we were just returning the current time for both. If the guest
> is unlucky enough to read TIME_LOW and TIME_HIGH either side of an
> overflow of the lower half, it will see time be in the future, before
> jumping backwards on the next read, and Linux currently relies on the
> atomicity guaranteed by the spec so is affected by this. Fix this
> violation of the spec by caching the correct value for TIME_HIGH
> whenever TIME_LOW is read, and returning that value for any TIME_HIGH
> read.
> 
> Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
> ---
>  hw/rtc/goldfish_rtc.c         | 14 ++++++++++++--
>  include/hw/rtc/goldfish_rtc.h |  1 +
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/rtc/goldfish_rtc.c b/hw/rtc/goldfish_rtc.c
> index 01e9d2b083..9b577bf159 100644
> --- a/hw/rtc/goldfish_rtc.c
> +++ b/hw/rtc/goldfish_rtc.c
> @@ -94,12 +94,22 @@ static uint64_t goldfish_rtc_read(void *opaque, hwaddr offset,
>      GoldfishRTCState *s = opaque;
>      uint64_t r = 0;
>  
> +    /*
> +     * From the documentation linked at the top of the file:
> +     *
> +     *   To read the value, the kernel must perform an IO_READ(TIME_LOW), which
> +     *   returns an unsigned 32-bit value, before an IO_READ(TIME_HIGH), which
> +     *   returns a signed 32-bit value, corresponding to the higher half of the
> +     *   full value.
> +     */
>      switch (offset) {
>      case RTC_TIME_LOW:
> -        r = goldfish_rtc_get_count(s) & 0xffffffff;
> +        r = goldfish_rtc_get_count(s);
> +        s->time_high = r >> 32;
> +        r &= 0xffffffff;
>          break;
>      case RTC_TIME_HIGH:
> -        r = goldfish_rtc_get_count(s) >> 32;
> +        r = s->time_high;
>          break;
>      case RTC_ALARM_LOW:
>          r = s->alarm_next & 0xffffffff;
> diff --git a/include/hw/rtc/goldfish_rtc.h b/include/hw/rtc/goldfish_rtc.h
> index 16f9f9e29d..9bd8924f5f 100644
> --- a/include/hw/rtc/goldfish_rtc.h
> +++ b/include/hw/rtc/goldfish_rtc.h
> @@ -41,6 +41,7 @@ typedef struct GoldfishRTCState {
>      uint32_t alarm_running;
>      uint32_t irq_pending;
>      uint32_t irq_enabled;
> +    uint32_t time_high;
>  } GoldfishRTCState;

You need to add the new field to goldfish_rtc_vmstate, and increment the version.


r~


^ permalink raw reply

* Re: [PATCH ghak90 V9 08/13] audit: add containerid support for user records
From: Richard Guy Briggs @ 2020-07-18  0:43 UTC (permalink / raw)
  To: Paul Moore
  Cc: nhorman, linux-api, containers, LKML, dhowells,
	Linux-Audit Mailing List, netfilter-devel, ebiederm, simo, netdev,
	linux-fsdevel, Eric Paris, mpatel, Serge Hallyn
In-Reply-To: <CAHC9VhSwMEZrq0dnaXmPi=bu0NgUtWPuw-2UGDrQa6TwxWkZtw@mail.gmail.com>

On 2020-07-05 11:11, Paul Moore wrote:
> On Sat, Jun 27, 2020 at 9:23 AM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > Add audit container identifier auxiliary record to user event standalone
> > records.
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > Acked-by: Neil Horman <nhorman@tuxdriver.com>
> > Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
> > ---
> >  kernel/audit.c | 19 ++++++++++++-------
> >  1 file changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 54dd2cb69402..997c34178ee8 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -1507,6 +1504,14 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> >                                 audit_log_n_untrustedstring(ab, str, data_len);
> >                         }
> >                         audit_log_end(ab);
> > +                       rcu_read_lock();
> > +                       cont = _audit_contobj_get(current);
> > +                       rcu_read_unlock();
> > +                       audit_log_container_id(context, cont);
> > +                       rcu_read_lock();
> > +                       _audit_contobj_put(cont);
> > +                       rcu_read_unlock();
> > +                       audit_free_context(context);
> 
> I haven't searched the entire patchset, but it seems like the pattern
> above happens a couple of times in this patchset, yes?  If so would it
> make sense to wrap the above get/log/put in a helper function?

I've redone the locking with an rcu lock around the get and a spinlock
around the put.  It occurs to me that putting an rcu lock around the
whole thing and doing a get without the refcount increment would save
us the spinlock and put and be fine since we'd be fine with stale but
consistent information traversing the contobj list from this point to
report it.  Problem with that is needing to use GFP_ATOMIC due to the
rcu lock.  If I stick with the spinlock around the put then I can use
GFP_KERNEL and just grab the spinlock while traversing the contobj list.

> Not a big deal either way, I'm pretty neutral on it at this point in
> the patchset but thought it might be worth mentioning in case you
> noticed the same and were on the fence.

There is only one other place this is used, in audit_log_exit in
auditsc.c.  I had noted the pattern but wasn't sure it was worth it.
Inline or not?  Should we just let the compiler decide?

> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635


^ permalink raw reply

* Re: [PATCH v2] fs/direct-io: fix one-time init of ->s_dio_done_wq
From: Eric Biggers @ 2020-07-18  0:42 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-fsdevel, linux-xfs, linux-ext4
In-Reply-To: <20200718001536.GB2005@dread.disaster.area>

Hi Dave,

On Sat, Jul 18, 2020 at 10:15:36AM +1000, Dave Chinner wrote:
> On Thu, Jul 16, 2020 at 10:05:10PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Correctly implement the "one-time" init pattern for ->s_dio_done_wq.
> > This fixes the following issues:
> > 
> > - The LKMM doesn't guarantee that the workqueue will be seen initialized
> >   before being used, if another CPU allocated it.  With regards to
> >   specific CPU architectures, this is true on at least Alpha, but it may
> >   be true on other architectures too if the internal implementation of
> >   workqueues causes use of the workqueue to involve a control
> >   dependency.  (There doesn't appear to be a control dependency
> >   currently, but it's hard to tell and it could change in the future.)
> > 
> > - The preliminary checks for sb->s_dio_done_wq are a data race, since
> >   they do a plain load of a concurrently modified variable.  According
> >   to the C standard, this undefined behavior.  In practice, the kernel
> >   does sometimes makes assumptions about data races might be okay in
> >   practice, but these rules are undocumented and not uniformly agreed
> >   upon, so it's best to avoid cases where they might come into play.
> > 
> > Following the guidance for one-time init I've proposed at
> > https://lkml.kernel.org/r/20200717044427.68747-1-ebiggers@kernel.org,
> > replace it with the simplest implementation that is guaranteed to be
> > correct while still achieving the following properties:
> > 
> >     - Doesn't make direct I/O users contend on a mutex in the fast path.
> > 
> >     - Doesn't allocate the workqueue when it will never be used.
> > 
> > Fixes: 7b7a8665edd8 ("direct-io: Implement generic deferred AIO completions")
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > ---
> > 
> > v2: new implementation using smp_load_acquire() + smp_store_release()
> >     and a mutex.
> 
> A mutex?
> 
> That's over-engineered premature optimisation - the allocation path
> is a slow path that will only ever be hit only on the first few
> direct IOs if an app manages to synchronise it's first ever
> concurrent DIOs to different files perfectly. There is zero need to
> "optimise" the code like this.

You're completely misunderstanding the point of this change.  The mutex version
is actually simpler and easier to get right than the cmpxchg() version (which
what I'm replacing) -- see the tools/memory-model/Documentation/ patch I've
proposed which explains this.  In fact the existing use of cmpxchg() is wrong,
since cmpxchg() doesn't guarantee an ACQUIRE barrier on failure.

> 
> I've already suggested that we get rid of this whole dynamic
> initialisation code out of the direct IO path altogether for good
> reason: all of this goes away and we don't have to care about
> optimising it for performance at all.
> 
> We have two options as I see it: always allocate the workqueue on
> direct IO capable filesytsems in their ->fill_super() method, or
> allocate it on the first open(O_DIRECT) where we check if O_DIRECT
> is supported by the filesystem.
> 
> i.e. do_dentry_open() does this:
> 
>         /* NB: we're sure to have correct a_ops only after f_op->open */
>         if (f->f_flags & O_DIRECT) {
>                 if (!f->f_mapping->a_ops || !f->f_mapping->a_ops->direct_IO)
>                         return -EINVAL;
>         }
> 
> Allocate the work queue there, and we don't need to care about how
> fast or slow setting up the workqueue is and so there is zero need
> to optimise it for speed.

You also suggested about 4 other different things, so I don't know which one you
actually want.  Now you're still suggesting multiple different things.

Not having to add filesystem-specific code to nearly every filesystem and not
allocating the workqueue when it won't be used are desirable properties to have,
and I think worth using one-time-init for.

Multiple threads can execute do_dentry_open() concurrently on the same
filesystem, so we'd still have to use one-time init for that.  Is your proposal
to do that and use the implementation where the mutex is unconditionally taken?

- Eric

^ permalink raw reply

* Re: [PATCH v2 2/6] dt-bindings: interconnect: Add property to set BCM TCS wait behavior
From: Mike Tipton @ 2020-07-18  0:41 UTC (permalink / raw)
  To: Rob Herring
  Cc: georgi.djakov, bjorn.andersson, agross, linux-pm, linux-arm-msm,
	devicetree, linux-kernel
In-Reply-To: <20200710163119.GA2753833@bogus>

On 7/10/2020 9:31 AM, Rob Herring wrote:
> On Thu, Jul 09, 2020 at 06:56:48PM -0700, Mike Tipton wrote:
>> Add "qcom,tcs-wait" property to set which TCS should wait for completion
>> when triggering.
>>
>> Signed-off-by: Mike Tipton <mdtipton@codeaurora.org>
>> ---
>>   .../bindings/interconnect/qcom,bcm-voter.yaml       | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
>> index 5971fc1df08d..f0c3d6b01831 100644
>> --- a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
>> @@ -21,6 +21,16 @@ properties:
>>       enum:
>>         - qcom,bcm-voter
>>   
>> +  qcom,tcs-wait:
>> +    description: |
>> +      Optional mask of which TCSs (Triggered Command Sets) wait for completion
>> +      upon triggering. In most cases, it's necessary to wait in both the AMC
>> +      and WAKE sets to ensure resources are available before use. If a specific
>> +      RSC and its use cases can ensure sufficient delay by other means, then
>> +      this can be overridden to reduce latencies.
> 
> I have no idea what any of this means to provide any meaningful comment.
> 
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    default: QCOM_ICC_TAG_ACTIVE_ONLY
> 
> Can't use defines here.

What's the recommended alternative? The meaning isn't obvious as a raw 
number (3). We expect the defines to be used in the dt files themselves 
(see example below). Is this just a restriction for the `default` 
documentation specifically? I could just mention the default behavior in 
the description I suppose, but that seems to defeat the purpose of 
having a separate `default` key.

> 
>> +
>>   required:
>>     - compatible
>>   
>> @@ -39,7 +49,10 @@ examples:
>>     # as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt
>>     - |
>>   
>> +    #include <dt-bindings/interconnect/qcom,icc.h>
>> +
>>       disp_bcm_voter: bcm_voter {
>>           compatible = "qcom,bcm-voter";
>> +        qcom,tcs-wait = <QCOM_ICC_TAG_AMC>;
>>       };
>>   ...
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>

^ permalink raw reply

* [sashal-linux-stable:queue-5.4 73/106] drivers/usb/musb/mediatek.c:202:18: error: implicit declaration of function 'musb_clearb'; did you mean
From: kernel test robot @ 2020-07-18  0:39 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 11345 bytes --]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git queue-5.4
head:   8fc787b62d0c673cca994da068df84905ddea333
commit: eec346066d383e736228ada2a0c24e6ac8369619 [73/106] usb: musb: Add support for MediaTek musb controller
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout eec346066d383e736228ada2a0c24e6ac8369619
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=alpha 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   drivers/usb/musb/mediatek.c: In function 'generic_interrupt':
>> drivers/usb/musb/mediatek.c:202:18: error: implicit declaration of function 'musb_clearb'; did you mean 'musb_readb'? [-Werror=implicit-function-declaration]
     202 |  musb->int_usb = musb_clearb(musb->mregs, MUSB_INTRUSB);
         |                  ^~~~~~~~~~~
         |                  musb_readb
>> drivers/usb/musb/mediatek.c:203:17: error: implicit declaration of function 'musb_clearw'; did you mean 'musb_readw'? [-Werror=implicit-function-declaration]
     203 |  musb->int_rx = musb_clearw(musb->mregs, MUSB_INTRRX);
         |                 ^~~~~~~~~~~
         |                 musb_readw
   drivers/usb/musb/mediatek.c: At top level:
>> drivers/usb/musb/mediatek.c:392:3: error: 'const struct musb_platform_ops' has no member named 'get_toggle'
     392 |  .get_toggle = mtk_musb_get_toggle,
         |   ^~~~~~~~~~
>> drivers/usb/musb/mediatek.c:392:16: error: initialization of 'int (*)(struct musb *)' from incompatible pointer type 'u16 (*)(struct musb_qh *, int)' {aka 'short unsigned int (*)(struct musb_qh *, int)'} [-Werror=incompatible-pointer-types]
     392 |  .get_toggle = mtk_musb_get_toggle,
         |                ^~~~~~~~~~~~~~~~~~~
   drivers/usb/musb/mediatek.c:392:16: note: (near initialization for 'mtk_musb_ops.exit')
>> drivers/usb/musb/mediatek.c:393:3: error: 'const struct musb_platform_ops' has no member named 'set_toggle'; did you mean 'set_mode'?
     393 |  .set_toggle = mtk_musb_set_toggle,
         |   ^~~~~~~~~~
         |   set_mode
>> drivers/usb/musb/mediatek.c:393:16: error: initialization of 'void (*)(struct musb *)' from incompatible pointer type 'u16 (*)(struct musb_qh *, int,  struct urb *)' {aka 'short unsigned int (*)(struct musb_qh *, int,  struct urb *)'} [-Werror=incompatible-pointer-types]
     393 |  .set_toggle = mtk_musb_set_toggle,
         |                ^~~~~~~~~~~~~~~~~~~
   drivers/usb/musb/mediatek.c:393:16: note: (near initialization for 'mtk_musb_ops.enable')
>> drivers/usb/musb/mediatek.c:394:10: warning: initialized field overwritten [-Woverride-init]
     394 |  .exit = mtk_musb_exit,
         |          ^~~~~~~~~~~~~
   drivers/usb/musb/mediatek.c:394:10: note: (near initialization for 'mtk_musb_ops.exit')
>> drivers/usb/musb/mediatek.c:399:3: error: 'const struct musb_platform_ops' has no member named 'clearb'
     399 |  .clearb = mtk_musb_clearb,
         |   ^~~~~~
>> drivers/usb/musb/mediatek.c:399:12: error: initialization of 'void (*)(struct musb *)' from incompatible pointer type 'u8 (*)(void *, unsigned int)' {aka 'unsigned char (*)(void *, unsigned int)'} [-Werror=incompatible-pointer-types]
     399 |  .clearb = mtk_musb_clearb,
         |            ^~~~~~~~~~~~~~~
   drivers/usb/musb/mediatek.c:399:12: note: (near initialization for 'mtk_musb_ops.enable')
   drivers/usb/musb/mediatek.c:399:12: warning: initialized field overwritten [-Woverride-init]
   drivers/usb/musb/mediatek.c:399:12: note: (near initialization for 'mtk_musb_ops.enable')
>> drivers/usb/musb/mediatek.c:400:3: error: 'const struct musb_platform_ops' has no member named 'clearw'
     400 |  .clearw = mtk_musb_clearw,
         |   ^~~~~~
>> drivers/usb/musb/mediatek.c:400:12: error: initialization of 'void (*)(struct musb *)' from incompatible pointer type 'u16 (*)(void *, unsigned int)' {aka 'short unsigned int (*)(void *, unsigned int)'} [-Werror=incompatible-pointer-types]
     400 |  .clearw = mtk_musb_clearw,
         |            ^~~~~~~~~~~~~~~
   drivers/usb/musb/mediatek.c:400:12: note: (near initialization for 'mtk_musb_ops.disable')
   cc1: some warnings being treated as errors

vim +202 drivers/usb/musb/mediatek.c

   194	
   195	static irqreturn_t generic_interrupt(int irq, void *__hci)
   196	{
   197		unsigned long flags;
   198		irqreturn_t retval = IRQ_NONE;
   199		struct musb *musb = __hci;
   200	
   201		spin_lock_irqsave(&musb->lock, flags);
 > 202		musb->int_usb = musb_clearb(musb->mregs, MUSB_INTRUSB);
 > 203		musb->int_rx = musb_clearw(musb->mregs, MUSB_INTRRX);
   204		musb->int_tx = musb_clearw(musb->mregs, MUSB_INTRTX);
   205	
   206		if (musb->int_usb || musb->int_tx || musb->int_rx)
   207			retval = musb_interrupt(musb);
   208	
   209		spin_unlock_irqrestore(&musb->lock, flags);
   210	
   211		return retval;
   212	}
   213	
   214	static irqreturn_t mtk_musb_interrupt(int irq, void *dev_id)
   215	{
   216		irqreturn_t retval = IRQ_NONE;
   217		struct musb *musb = (struct musb *)dev_id;
   218		u32 l1_ints;
   219	
   220		l1_ints = musb_readl(musb->mregs, USB_L1INTS) &
   221				musb_readl(musb->mregs, USB_L1INTM);
   222	
   223		if (l1_ints & (TX_INT_STATUS | RX_INT_STATUS | USBCOM_INT_STATUS))
   224			retval = generic_interrupt(irq, musb);
   225	
   226	#if defined(CONFIG_USB_INVENTRA_DMA)
   227		if (l1_ints & DMA_INT_STATUS)
   228			retval = dma_controller_irq(irq, musb->dma_controller);
   229	#endif
   230		return retval;
   231	}
   232	
   233	static u32 mtk_musb_busctl_offset(u8 epnum, u16 offset)
   234	{
   235		return MTK_MUSB_TXFUNCADDR + offset + 8 * epnum;
   236	}
   237	
   238	static u8 mtk_musb_clearb(void __iomem *addr, unsigned int offset)
   239	{
   240		u8 data;
   241	
   242		/* W1C */
   243		data = musb_readb(addr, offset);
   244		musb_writeb(addr, offset, data);
   245		return data;
   246	}
   247	
   248	static u16 mtk_musb_clearw(void __iomem *addr, unsigned int offset)
   249	{
   250		u16 data;
   251	
   252		/* W1C */
   253		data = musb_readw(addr, offset);
   254		musb_writew(addr, offset, data);
   255		return data;
   256	}
   257	
   258	static int mtk_musb_set_mode(struct musb *musb, u8 mode)
   259	{
   260		struct device *dev = musb->controller;
   261		struct mtk_glue *glue = dev_get_drvdata(dev->parent);
   262		enum phy_mode new_mode;
   263		enum usb_role new_role;
   264	
   265		switch (mode) {
   266		case MUSB_HOST:
   267			new_mode = PHY_MODE_USB_HOST;
   268			new_role = USB_ROLE_HOST;
   269			break;
   270		case MUSB_PERIPHERAL:
   271			new_mode = PHY_MODE_USB_DEVICE;
   272			new_role = USB_ROLE_DEVICE;
   273			break;
   274		case MUSB_OTG:
   275			new_mode = PHY_MODE_USB_OTG;
   276			new_role = USB_ROLE_NONE;
   277			break;
   278		default:
   279			dev_err(glue->dev, "Invalid mode request\n");
   280			return -EINVAL;
   281		}
   282	
   283		if (glue->phy_mode == new_mode)
   284			return 0;
   285	
   286		if (musb->port_mode != MUSB_OTG) {
   287			dev_err(glue->dev, "Does not support changing modes\n");
   288			return -EINVAL;
   289		}
   290	
   291		glue->role = new_role;
   292		musb_usb_role_sx_set(dev, glue->role);
   293		return 0;
   294	}
   295	
   296	static int mtk_musb_init(struct musb *musb)
   297	{
   298		struct device *dev = musb->controller;
   299		struct mtk_glue *glue = dev_get_drvdata(dev->parent);
   300		int ret;
   301	
   302		glue->musb = musb;
   303		musb->phy = glue->phy;
   304		musb->xceiv = glue->xceiv;
   305		musb->is_host = false;
   306		musb->isr = mtk_musb_interrupt;
   307	
   308		/* Set TX/RX toggle enable */
   309		musb_writew(musb->mregs, MUSB_TXTOGEN, MTK_TOGGLE_EN);
   310		musb_writew(musb->mregs, MUSB_RXTOGEN, MTK_TOGGLE_EN);
   311	
   312		if (musb->port_mode == MUSB_OTG) {
   313			ret = mtk_otg_switch_init(glue);
   314			if (ret)
   315				return ret;
   316		}
   317	
   318		ret = phy_init(glue->phy);
   319		if (ret)
   320			goto err_phy_init;
   321	
   322		ret = phy_power_on(glue->phy);
   323		if (ret)
   324			goto err_phy_power_on;
   325	
   326		phy_set_mode(glue->phy, glue->phy_mode);
   327	
   328	#if defined(CONFIG_USB_INVENTRA_DMA)
   329		musb_writel(musb->mregs, MUSB_HSDMA_INTR,
   330			    DMA_INTR_STATUS_MSK | DMA_INTR_UNMASK_SET_MSK);
   331	#endif
   332		musb_writel(musb->mregs, USB_L1INTM, TX_INT_STATUS | RX_INT_STATUS |
   333			    USBCOM_INT_STATUS | DMA_INT_STATUS);
   334		return 0;
   335	
   336	err_phy_power_on:
   337		phy_exit(glue->phy);
   338	err_phy_init:
   339		mtk_otg_switch_exit(glue);
   340		return ret;
   341	}
   342	
   343	static u16 mtk_musb_get_toggle(struct musb_qh *qh, int is_out)
   344	{
   345		struct musb *musb = qh->hw_ep->musb;
   346		u8 epnum = qh->hw_ep->epnum;
   347		u16 toggle;
   348	
   349		toggle = musb_readw(musb->mregs, is_out ? MUSB_TXTOG : MUSB_RXTOG);
   350		return toggle & (1 << epnum);
   351	}
   352	
   353	static u16 mtk_musb_set_toggle(struct musb_qh *qh, int is_out, struct urb *urb)
   354	{
   355		struct musb *musb = qh->hw_ep->musb;
   356		u8 epnum = qh->hw_ep->epnum;
   357		u16 value, toggle;
   358	
   359		toggle = usb_gettoggle(urb->dev, qh->epnum, is_out);
   360	
   361		if (is_out) {
   362			value = musb_readw(musb->mregs, MUSB_TXTOG);
   363			value |= toggle << epnum;
   364			musb_writew(musb->mregs, MUSB_TXTOG, value);
   365		} else {
   366			value = musb_readw(musb->mregs, MUSB_RXTOG);
   367			value |= toggle << epnum;
   368			musb_writew(musb->mregs, MUSB_RXTOG, value);
   369		}
   370	
   371		return 0;
   372	}
   373	
   374	static int mtk_musb_exit(struct musb *musb)
   375	{
   376		struct device *dev = musb->controller;
   377		struct mtk_glue *glue = dev_get_drvdata(dev->parent);
   378	
   379		mtk_otg_switch_exit(glue);
   380		phy_power_off(glue->phy);
   381		phy_exit(glue->phy);
   382		mtk_musb_clks_disable(glue);
   383	
   384		pm_runtime_put_sync(dev);
   385		pm_runtime_disable(dev);
   386		return 0;
   387	}
   388	
   389	static const struct musb_platform_ops mtk_musb_ops = {
   390		.quirks = MUSB_DMA_INVENTRA,
   391		.init = mtk_musb_init,
 > 392		.get_toggle = mtk_musb_get_toggle,
 > 393		.set_toggle = mtk_musb_set_toggle,
 > 394		.exit = mtk_musb_exit,
   395	#ifdef CONFIG_USB_INVENTRA_DMA
   396		.dma_init = musbhs_dma_controller_create_noirq,
   397		.dma_exit = musbhs_dma_controller_destroy,
   398	#endif
 > 399		.clearb = mtk_musb_clearb,
 > 400		.clearw = mtk_musb_clearw,
   401		.busctl_offset = mtk_musb_busctl_offset,
   402		.set_mode = mtk_musb_set_mode,
   403	};
   404	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 58974 bytes --]

^ permalink raw reply

* [tpm2] tpm2-tss v3.0.0-rc0
From: Tadeusz Struk @ 2020-07-18  0:34 UTC (permalink / raw)
  To: tpm2

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Hello,
I'm happy to announce the first release candidate for tpm2-tss v3.0.0.
It can be found here:
https://github.com/tpm2-software/tpm2-tss/releases/tag/3.0.0-rc0

There are two backwards compatibility breaking changes between 3.0.0 and
2.4.x.

As always all the changes and fixes are listed in the CHANGELOG.md file.
Any feedback welcomed.

Thanks,
-- 
Tadeusz

^ permalink raw reply

* [tpm2] tpm2-tss v2.4.2-rc3
From: Tadeusz Struk @ 2020-07-18  0:33 UTC (permalink / raw)
  To: tpm2

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

Hello,
I'm happy to announce that a new release candidate for tpm2-tss
v2.4.2-rc3 is out.
https://github.com/tpm2-software/tpm2-tss/releases/tag/2.4.2-rc3

All changes and fixes are listed in the CHANGELOG.md file.
Any feedback welcomed.

Thanks,
-- 
Tadeusz

^ permalink raw reply

* Re: [PATCH 17/18] drm/arc: Move to drm/tiny
From: kernel test robot @ 2020-07-18  0:33 UTC (permalink / raw)
  To: Daniel Vetter, DRI Development
  Cc: clang-built-linux, Alexey Brodkin, kbuild-all, Daniel Vetter
In-Reply-To: <20200717090430.1146256-17-daniel.vetter@ffwll.ch>

[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]

Hi Daniel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.8-rc5 next-20200717]
[cannot apply to arm/drm-armada-devel arm/drm-armada-fixes]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-armada-Use-devm_drm_dev_alloc/20200717-170827
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project ed6b578040a85977026c93bf4188f996148f3218)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/tiny/arcpgu.c:137:36: warning: unused variable 'arc_pgu_crtc_funcs' [-Wunused-const-variable]
   static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
                                      ^
   1 warning generated.

vim +/arc_pgu_crtc_funcs +137 drivers/gpu/drm/tiny/arcpgu.c

bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  136  
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 @137  static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  138  	.destroy = drm_crtc_cleanup,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  139  	.set_config = drm_atomic_helper_set_config,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  140  	.page_flip = drm_atomic_helper_page_flip,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  141  	.reset = drm_atomic_helper_crtc_reset,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  142  	.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  143  	.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  144  };
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  145  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 75358 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH bpf-next 2/2] bpf: compute bpf_skc_to_*() helper socket btf ids at build time
From: kernel test robot @ 2020-07-18  0:33 UTC (permalink / raw)
  To: kbuild-all
In-Reply-To: <20200717184707.3477423-1-yhs@fb.com>

[-- Attachment #1: Type: text/plain, Size: 3430 bytes --]

Hi Yonghong,

I love your patch! Yet something to improve:

[auto build test ERROR on bpf-next/master]

url:    https://github.com/0day-ci/linux/commits/Yonghong-Song/compute-bpf_skc_to_-helper-socket-btf-ids-at-build-time/20200718-025117
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: x86_64-rhel-7.6-kselftests (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
        # save the attached .config to linux build tree
        make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from net/core/filter.c:78:
   net/core/filter.c:3783:13: warning: array 'bpf_skb_output_btf_ids' assumed to have one element
    3783 | BTF_ID_LIST(bpf_skb_output_btf_ids)
         |             ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/btf_ids.h:69:12: note: in definition of macro 'BTF_ID_LIST'
      69 | static u32 name[];
         |            ^~~~
   net/core/filter.c:4179:13: warning: array 'bpf_xdp_output_btf_ids' assumed to have one element
    4179 | BTF_ID_LIST(bpf_xdp_output_btf_ids)
         |             ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/btf_ids.h:69:12: note: in definition of macro 'BTF_ID_LIST'
      69 | static u32 name[];
         |            ^~~~
>> net/core/filter.c:9268:13: warning: array 'btf_sock_ids' assumed to have one element
    9268 | BTF_ID_LIST(btf_sock_ids)
         |             ^~~~~~~~~~~~
   include/linux/btf_ids.h:69:12: note: in definition of macro 'BTF_ID_LIST'
      69 | static u32 name[];
         |            ^~~~
   /tmp/ccDB7ajn.s: Assembler messages:
>> /tmp/ccDB7ajn.s:66247: Error: symbol `btf_sock_ids' is already defined
   /tmp/ccDB7ajn.s:67196: Error: symbol `bpf_xdp_output_btf_ids' is already defined
   /tmp/ccDB7ajn.s:67344: Error: symbol `bpf_skb_output_btf_ids' is already defined
--
   In file included from net/core/filter.c:78:
   net/core/filter.c:3783:13: warning: array 'bpf_skb_output_btf_ids' assumed to have one element
    3783 | BTF_ID_LIST(bpf_skb_output_btf_ids)
         |             ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/btf_ids.h:69:12: note: in definition of macro 'BTF_ID_LIST'
      69 | static u32 name[];
         |            ^~~~
   net/core/filter.c:4179:13: warning: array 'bpf_xdp_output_btf_ids' assumed to have one element
    4179 | BTF_ID_LIST(bpf_xdp_output_btf_ids)
         |             ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/btf_ids.h:69:12: note: in definition of macro 'BTF_ID_LIST'
      69 | static u32 name[];
         |            ^~~~
>> net/core/filter.c:9268:13: warning: array 'btf_sock_ids' assumed to have one element
    9268 | BTF_ID_LIST(btf_sock_ids)
         |             ^~~~~~~~~~~~
   include/linux/btf_ids.h:69:12: note: in definition of macro 'BTF_ID_LIST'
      69 | static u32 name[];
         |            ^~~~
   /tmp/cc1GpKvw.s: Assembler messages:
   /tmp/cc1GpKvw.s:66247: Error: symbol `btf_sock_ids' is already defined
   /tmp/cc1GpKvw.s:67196: Error: symbol `bpf_xdp_output_btf_ids' is already defined
   /tmp/cc1GpKvw.s:67344: Error: symbol `bpf_skb_output_btf_ids' is already defined

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 50002 bytes --]

^ permalink raw reply

* Re: [PATCH 17/18] drm/arc: Move to drm/tiny
From: kernel test robot @ 2020-07-18  0:33 UTC (permalink / raw)
  To: kbuild-all
In-Reply-To: <20200717090430.1146256-17-daniel.vetter@ffwll.ch>

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

Hi Daniel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.8-rc5 next-20200717]
[cannot apply to arm/drm-armada-devel arm/drm-armada-fixes]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-armada-Use-devm_drm_dev_alloc/20200717-170827
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project ed6b578040a85977026c93bf4188f996148f3218)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/tiny/arcpgu.c:137:36: warning: unused variable 'arc_pgu_crtc_funcs' [-Wunused-const-variable]
   static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
                                      ^
   1 warning generated.

vim +/arc_pgu_crtc_funcs +137 drivers/gpu/drm/tiny/arcpgu.c

bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  136  
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 @137  static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  138  	.destroy = drm_crtc_cleanup,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  139  	.set_config = drm_atomic_helper_set_config,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  140  	.page_flip = drm_atomic_helper_page_flip,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  141  	.reset = drm_atomic_helper_crtc_reset,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  142  	.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  143  	.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  144  };
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17  145  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 75358 bytes --]

^ permalink raw reply

* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow privileged user to map the OA buffer (rev2)
From: Patchwork @ 2020-07-18  0:30 UTC (permalink / raw)
  To: Umesh Nerlige Ramappa; +Cc: intel-gfx
In-Reply-To: <20200718000437.69033-1-umesh.nerlige.ramappa@intel.com>

== Series Details ==

Series: Allow privileged user to map the OA buffer (rev2)
URL   : https://patchwork.freedesktop.org/series/79460/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Allow privileged user to map the OA buffer (rev2)
From: Patchwork @ 2020-07-18  0:29 UTC (permalink / raw)
  To: Umesh Nerlige Ramappa; +Cc: intel-gfx
In-Reply-To: <20200718000437.69033-1-umesh.nerlige.ramappa@intel.com>

== Series Details ==

Series: Allow privileged user to map the OA buffer (rev2)
URL   : https://patchwork.freedesktop.org/series/79460/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
24740597e5f9 drm/i915/perf: Ensure observation logic is not clock gated
216ee54f6578 drm/i915/perf: Whitelist OA report trigger registers
829409416d4b drm/i915/perf: Whitelist OA counter and buffer registers
dac9a1608e77 drm/i915/perf: Map OA buffer to user space for gen12 performance query
-:47: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#47: 
- Pass non-zero offset in mmap to enforce the right object is mapped (Chris)

total: 0 errors, 1 warnings, 0 checks, 281 lines checked


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* [renesas-devel:renesas-arm-dt-for-v5.9] BUILD SUCCESS 8aa937cb4aebc31746ceed1c28b20557ef105f08
From: kernel test robot @ 2020-07-18  0:26 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: linux-renesas-soc

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git  renesas-arm-dt-for-v5.9
branch HEAD: 8aa937cb4aebc31746ceed1c28b20557ef105f08  ARM: dts: sh73a0: Add missing clocks to sound node

elapsed time: 725m

configs tested: 86
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
nds32                             allnoconfig
powerpc                      ppc64e_defconfig
arm                           viper_defconfig
ia64                             alldefconfig
sh                           se7721_defconfig
ia64                          tiger_defconfig
mips                        jmr3927_defconfig
arm                            xcep_defconfig
h8300                            allyesconfig
powerpc                 linkstation_defconfig
sparc                       sparc32_defconfig
arm                          badge4_defconfig
powerpc                      pmac32_defconfig
riscv                          rv32_defconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
nds32                               defconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply

* [renesas-devel:next] BUILD SUCCESS 344cb4f80fba071550975e18b7b6975c8addbbcf
From: kernel test robot @ 2020-07-18  0:26 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: linux-renesas-soc

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git  next
branch HEAD: 344cb4f80fba071550975e18b7b6975c8addbbcf  Merge branch 'renesas-arm-dt-for-v5.9' into renesas-next

elapsed time: 725m

configs tested: 100
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
nds32                             allnoconfig
powerpc                      ppc64e_defconfig
arm                           viper_defconfig
ia64                             alldefconfig
sh                           se7721_defconfig
arm                       aspeed_g4_defconfig
mips                           ip27_defconfig
m68k                        m5307c3_defconfig
sh                               j2_defconfig
powerpc                       ppc64_defconfig
parisc                           allyesconfig
h8300                            allyesconfig
powerpc                 linkstation_defconfig
sparc                       sparc32_defconfig
arm                          badge4_defconfig
powerpc                      pmac32_defconfig
riscv                          rv32_defconfig
i386                              allnoconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
nds32                               defconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allmodconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
powerpc                             defconfig
i386                 randconfig-a001-20200717
i386                 randconfig-a005-20200717
i386                 randconfig-a002-20200717
i386                 randconfig-a006-20200717
i386                 randconfig-a003-20200717
i386                 randconfig-a004-20200717
x86_64               randconfig-a005-20200717
x86_64               randconfig-a006-20200717
x86_64               randconfig-a002-20200717
x86_64               randconfig-a001-20200717
x86_64               randconfig-a003-20200717
x86_64               randconfig-a004-20200717
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply

* [igt-dev] ✗ Fi.CI.BAT: failure for series starting with [1/2] i915/perf: add tests for triggered OA reports
From: Patchwork @ 2020-07-18  0:26 UTC (permalink / raw)
  To: Umesh Nerlige Ramappa; +Cc: igt-dev
In-Reply-To: <20200717235842.68574-1-umesh.nerlige.ramappa@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 7382 bytes --]

== Series Details ==

Series: series starting with [1/2] i915/perf: add tests for triggered OA reports
URL   : https://patchwork.freedesktop.org/series/79617/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8761 -> IGTPW_4776
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_4776 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_4776, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_4776:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@gt_lrc:
    - fi-bsw-n3050:       [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html

  
Known issues
------------

  Here are the changes found in IGTPW_4776 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_suspend@basic-s0:
    - fi-tgl-u2:          [PASS][3] -> [FAIL][4] ([i915#1888])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
    - fi-icl-u2:          [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html

  * igt@vgem_basic@mmap:
    - fi-tgl-y:           [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-tgl-y/igt@vgem_basic@mmap.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-tgl-y/igt@vgem_basic@mmap.html

  
#### Possible fixes ####

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-tgl-y:           [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-tgl-y/igt@i915_pm_rpm@basic-pci-d3-state.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-tgl-y/igt@i915_pm_rpm@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
    - fi-kbl-guc:         [FAIL][11] ([i915#138]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html

  * igt@i915_selftest@live@execlists:
    - fi-cfl-8700k:       [INCOMPLETE][13] ([i915#2089]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-cfl-8700k/igt@i915_selftest@live@execlists.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-cfl-8700k/igt@i915_selftest@live@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-bsw-n3050:       [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - fi-icl-u2:          [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@prime_self_import@basic-with_two_bos:
    - fi-tgl-y:           [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
#### Warnings ####

  * igt@i915_pm_rpm@module-reload:
    - fi-kbl-x1275:       [SKIP][21] ([fdo#109271]) -> [DMESG-FAIL][22] ([i915#62])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
    - fi-kbl-x1275:       [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html

  * igt@kms_force_connector_basic@force-connector-state:
    - fi-kbl-x1275:       [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][26] ([i915#62] / [i915#92]) +4 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8761/fi-kbl-x1275/igt@kms_force_connector_basic@force-connector-state.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/fi-kbl-x1275/igt@kms_force_connector_basic@force-connector-state.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#138]: https://gitlab.freedesktop.org/drm/intel/issues/138
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2089]: https://gitlab.freedesktop.org/drm/intel/issues/2089
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (47 -> 40)
------------------------------

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_5739 -> IGTPW_4776

  CI-20190529: 20190529
  CI_DRM_8761: b665aabc40b8c7e86f10a74171d3d3fd71251781 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4776: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/index.html
  IGT_5739: 9b964d7359db9799f2b5b905403dda668ae28c87 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@perf@mapped-oa-buffer
+igt@perf@triggered-oa-reports

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4776/index.html

[-- Attachment #1.2: Type: text/html, Size: 9118 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply

* Re: [PATCH v7 0/5] dma: Add Xilinx ZynqMP DPDMA driver
From: Laurent Pinchart @ 2020-07-18  0:24 UTC (permalink / raw)
  To: Vinod Koul
  Cc: dmaengine, Michal Simek, Hyun Kwon, Tejas Upadhyay,
	Satish Kumar Nagireddy, Peter Ujfalusi
In-Reply-To: <20200717061120.GE82923@vkoul-mobl>

Hi Vinod,

On Fri, Jul 17, 2020 at 11:41:20AM +0530, Vinod Koul wrote:
> On 17-07-20, 04:33, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series adds a new driver for the DPDMA engine found in the
> > Xilinx ZynqMP.
> > 
> > The previous version can be found at [1]. All review comments have been
> > taken into account. The main changes are in the DPDMA driver, with
> > cleanups in the debugfs support, and handling of the !LOAD_EOT case when
> > preparing transactions.
> > 
> > The driver has been successfully tested with the ZynqMP DisplayPort
> > subsystem DRM driver.
> > 
> > As I would like to merge both this series and the DRM driver that
> > depends on it for v5.9 (if still possible), I have based those patches
> > on top of v5.8-rc1. There's unfortunately a conflict with the DMA engine
> > next branch, which is easy to resolve.
> > 
> > Vinod, if you're fine with the series, I can propose two ways forward:
> > 
> > - You can apply the patches on top of v5.8-rc1, push that to a base
> >   branch, merge it into the dmaengine -next branch, and push the base
> >   branch to a public git tree to let me base the DRM driver on it.
> 
> Applied 1-3 to dmaengine.git topic/xilinx, it should show up in -next
> later in the day

Thank you!

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* Re: [PATCH v7 4/5] dmaengine: xilinx: dpdma: Add debugfs support
From: Laurent Pinchart @ 2020-07-18  0:23 UTC (permalink / raw)
  To: Vinod Koul
  Cc: dmaengine, Michal Simek, Hyun Kwon, Tejas Upadhyay,
	Satish Kumar Nagireddy, Peter Ujfalusi
In-Reply-To: <20200717060515.GD82923@vkoul-mobl>

Hi Vinod,

On Fri, Jul 17, 2020 at 11:35:15AM +0530, Vinod Koul wrote:
> On 17-07-20, 04:33, Laurent Pinchart wrote:
> 
> > +static void xilinx_dpdma_debugfs_cleanup(struct xilinx_dpdma_device *xdev)
> > +{
> > +	debugfs_remove_recursive(xdev->debugfs_dir);
> 
> you can skip this step as core will do so when you call
> dma_async_device_unregister()
> 
> > +	xdev->debugfs_dir = NULL;
> > +}
> > +
> > +static int xilinx_dpdma_debugfs_init(struct xilinx_dpdma_device *xdev)
> > +{
> > +	struct dentry *dent;
> > +
> > +	dpdma_debugfs.testcase = DPDMA_TC_NONE;
> > +
> > +	dent = debugfs_create_dir("dpdma", xdev->common.dbg_dev_root);
> > +	if (IS_ERR(dent)) {
> > +		dev_err(xdev->dev, "Failed to create debugfs directory\n");
> > +		return -ENODEV;
> > +	}
> 
> Do you really need another dir in your device root. You should already
> have .../dmaengine/<dpdma-dev-name>/ adding dpdma dir seems overkill

It's indeed overkill. I'll remove it. Thanks for catching the issue.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [PATCH] goldfish_rtc: Fix non-atomic read behaviour of TIME_LOW/TIME_HIGH
From: Jessica Clarke @ 2020-07-18  0:20 UTC (permalink / raw)
  To: qemu-riscv; +Cc: Alistair Francis, Anup Patel, Jessica Clarke, qemu-devel

The specification says:

   0x00  TIME_LOW   R: Get current time, then return low-order 32-bits.
   0x04  TIME_HIGH  R: Return high 32-bits from previous TIME_LOW read.

   ...

   To read the value, the kernel must perform an IO_READ(TIME_LOW),
   which returns an unsigned 32-bit value, before an IO_READ(TIME_HIGH),
   which returns a signed 32-bit value, corresponding to the higher half
   of the full value.

However, we were just returning the current time for both. If the guest
is unlucky enough to read TIME_LOW and TIME_HIGH either side of an
overflow of the lower half, it will see time be in the future, before
jumping backwards on the next read, and Linux currently relies on the
atomicity guaranteed by the spec so is affected by this. Fix this
violation of the spec by caching the correct value for TIME_HIGH
whenever TIME_LOW is read, and returning that value for any TIME_HIGH
read.

Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
---
 hw/rtc/goldfish_rtc.c         | 14 ++++++++++++--
 include/hw/rtc/goldfish_rtc.h |  1 +
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/hw/rtc/goldfish_rtc.c b/hw/rtc/goldfish_rtc.c
index 01e9d2b083..9b577bf159 100644
--- a/hw/rtc/goldfish_rtc.c
+++ b/hw/rtc/goldfish_rtc.c
@@ -94,12 +94,22 @@ static uint64_t goldfish_rtc_read(void *opaque, hwaddr offset,
     GoldfishRTCState *s = opaque;
     uint64_t r = 0;
 
+    /*
+     * From the documentation linked at the top of the file:
+     *
+     *   To read the value, the kernel must perform an IO_READ(TIME_LOW), which
+     *   returns an unsigned 32-bit value, before an IO_READ(TIME_HIGH), which
+     *   returns a signed 32-bit value, corresponding to the higher half of the
+     *   full value.
+     */
     switch (offset) {
     case RTC_TIME_LOW:
-        r = goldfish_rtc_get_count(s) & 0xffffffff;
+        r = goldfish_rtc_get_count(s);
+        s->time_high = r >> 32;
+        r &= 0xffffffff;
         break;
     case RTC_TIME_HIGH:
-        r = goldfish_rtc_get_count(s) >> 32;
+        r = s->time_high;
         break;
     case RTC_ALARM_LOW:
         r = s->alarm_next & 0xffffffff;
diff --git a/include/hw/rtc/goldfish_rtc.h b/include/hw/rtc/goldfish_rtc.h
index 16f9f9e29d..9bd8924f5f 100644
--- a/include/hw/rtc/goldfish_rtc.h
+++ b/include/hw/rtc/goldfish_rtc.h
@@ -41,6 +41,7 @@ typedef struct GoldfishRTCState {
     uint32_t alarm_running;
     uint32_t irq_pending;
     uint32_t irq_enabled;
+    uint32_t time_high;
 } GoldfishRTCState;
 
 #endif
-- 
2.20.1



^ permalink raw reply related

* [PATCH] goldfish_rtc: Fix non-atomic read behaviour of TIME_LOW/TIME_HIGH
From: Jessica Clarke @ 2020-07-18  0:20 UTC (permalink / raw)
  To: qemu-riscv; +Cc: Jessica Clarke, qemu-devel, Anup Patel, Alistair Francis

The specification says:

   0x00  TIME_LOW   R: Get current time, then return low-order 32-bits.
   0x04  TIME_HIGH  R: Return high 32-bits from previous TIME_LOW read.

   ...

   To read the value, the kernel must perform an IO_READ(TIME_LOW),
   which returns an unsigned 32-bit value, before an IO_READ(TIME_HIGH),
   which returns a signed 32-bit value, corresponding to the higher half
   of the full value.

However, we were just returning the current time for both. If the guest
is unlucky enough to read TIME_LOW and TIME_HIGH either side of an
overflow of the lower half, it will see time be in the future, before
jumping backwards on the next read, and Linux currently relies on the
atomicity guaranteed by the spec so is affected by this. Fix this
violation of the spec by caching the correct value for TIME_HIGH
whenever TIME_LOW is read, and returning that value for any TIME_HIGH
read.

Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
---
 hw/rtc/goldfish_rtc.c         | 14 ++++++++++++--
 include/hw/rtc/goldfish_rtc.h |  1 +
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/hw/rtc/goldfish_rtc.c b/hw/rtc/goldfish_rtc.c
index 01e9d2b083..9b577bf159 100644
--- a/hw/rtc/goldfish_rtc.c
+++ b/hw/rtc/goldfish_rtc.c
@@ -94,12 +94,22 @@ static uint64_t goldfish_rtc_read(void *opaque, hwaddr offset,
     GoldfishRTCState *s = opaque;
     uint64_t r = 0;
 
+    /*
+     * From the documentation linked at the top of the file:
+     *
+     *   To read the value, the kernel must perform an IO_READ(TIME_LOW), which
+     *   returns an unsigned 32-bit value, before an IO_READ(TIME_HIGH), which
+     *   returns a signed 32-bit value, corresponding to the higher half of the
+     *   full value.
+     */
     switch (offset) {
     case RTC_TIME_LOW:
-        r = goldfish_rtc_get_count(s) & 0xffffffff;
+        r = goldfish_rtc_get_count(s);
+        s->time_high = r >> 32;
+        r &= 0xffffffff;
         break;
     case RTC_TIME_HIGH:
-        r = goldfish_rtc_get_count(s) >> 32;
+        r = s->time_high;
         break;
     case RTC_ALARM_LOW:
         r = s->alarm_next & 0xffffffff;
diff --git a/include/hw/rtc/goldfish_rtc.h b/include/hw/rtc/goldfish_rtc.h
index 16f9f9e29d..9bd8924f5f 100644
--- a/include/hw/rtc/goldfish_rtc.h
+++ b/include/hw/rtc/goldfish_rtc.h
@@ -41,6 +41,7 @@ typedef struct GoldfishRTCState {
     uint32_t alarm_running;
     uint32_t irq_pending;
     uint32_t irq_enabled;
+    uint32_t time_high;
 } GoldfishRTCState;
 
 #endif
-- 
2.20.1



^ permalink raw reply related

* [sashal-linux-stable:queue-5.4 76/106] drivers/clk/sunxi-ng/ccu-sun8i-de2.c:223:14: error: 'sun50i_a64_de2_clks' undeclared here (not in a function); did you mean
From: kernel test robot @ 2020-07-18  0:20 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git queue-5.4
head:   8fc787b62d0c673cca994da068df84905ddea333
commit: b92fbb5378148d812c8b1c3025a909b72acbe8c3 [76/106] clk: sunxi-ng: sun8i-de2: Add R40 specific quirks
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout b92fbb5378148d812c8b1c3025a909b72acbe8c3
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/clk/sunxi-ng/ccu-sun8i-de2.c:223:14: error: 'sun50i_a64_de2_clks' undeclared here (not in a function); did you mean 'sun50i_h6_de3_clks'?
     223 |  .ccu_clks = sun50i_a64_de2_clks,
         |              ^~~~~~~~~~~~~~~~~~~
         |              sun50i_h6_de3_clks
   In file included from include/linux/kernel.h:16,
                    from include/linux/clk.h:13,
                    from drivers/clk/sunxi-ng/ccu-sun8i-de2.c:6:
>> include/linux/build_bug.h:16:45: error: bit-field '<anonymous>' width not an integer constant
      16 | #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
         |                                             ^
   include/linux/compiler.h:357:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
     357 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
         |                            ^~~~~~~~~~~~~~~~~
   include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
      47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
         |                                                           ^~~~~~~~~~~~~~~
   drivers/clk/sunxi-ng/ccu-sun8i-de2.c:224:18: note: in expansion of macro 'ARRAY_SIZE'
     224 |  .num_ccu_clks = ARRAY_SIZE(sun50i_a64_de2_clks),
         |                  ^~~~~~~~~~
>> drivers/clk/sunxi-ng/ccu-sun8i-de2.c:226:14: error: 'sun50i_a64_de2_hw_clks' undeclared here (not in a function); did you mean 'sun50i_h6_de3_hw_clks'?
     226 |  .hw_clks = &sun50i_a64_de2_hw_clks,
         |              ^~~~~~~~~~~~~~~~~~~~~~
         |              sun50i_h6_de3_hw_clks

vim +223 drivers/clk/sunxi-ng/ccu-sun8i-de2.c

   221	
   222	static const struct sunxi_ccu_desc sun8i_r40_de2_clk_desc = {
 > 223		.ccu_clks	= sun50i_a64_de2_clks,
   224		.num_ccu_clks	= ARRAY_SIZE(sun50i_a64_de2_clks),
   225	
 > 226		.hw_clks	= &sun50i_a64_de2_hw_clks,
   227	
   228		.resets		= sun8i_a83t_de2_resets,
   229		.num_resets	= ARRAY_SIZE(sun8i_a83t_de2_resets),
   230	};
   231	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 62768 bytes --]

^ permalink raw reply

* Re: [PATCH] syscall.h: fix comment
From: Thomas Gleixner @ 2020-07-18  0:20 UTC (permalink / raw)
  To: Bui Quang Minh, minhquangbui99, trivial; +Cc: linux-api
In-Reply-To: <20200717104517.2275-1-minhquangbui99@gmail.com>

Bui Quang Minh <minhquangbui99@gmail.com> writes:

> The comment shows wrong file name that contains the syscalls' definition
>
> Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
> ---
>  include/linux/syscalls.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 1815065d52f3..a3d053f715e2 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -741,7 +741,7 @@ asmlinkage long sys_settimeofday(struct __kernel_old_timeval __user *tv,
>  asmlinkage long sys_adjtimex(struct __kernel_timex __user *txc_p);
>  asmlinkage long sys_adjtimex_time32(struct old_timex32 __user *txc_p);
>  
> -/* kernel/timer.c */
> +/* kernel/sys.c */

How about just removing the file reference completely. It has no value
at all.

Thanks,

        tglx

^ permalink raw reply

* Re: [PATCH v6 0/9] remoteproc: Add support for attaching with rproc
From: patchwork-bot+linux-remoteproc @ 2020-07-18  0:20 UTC (permalink / raw)
  To: Mathieu Poirier; +Cc: linux-remoteproc
In-Reply-To: <20200714195035.1426873-1-mathieu.poirier@linaro.org>

Hello:

This series was applied to andersson/remoteproc.git (refs/heads/for-next).

On Tue, 14 Jul 2020 13:50:26 -0600 you wrote:
> This set provides functionality allowing the remoteproc core to attach to
> a remote processor that was started by another entity.
> 
> New in V6:
> 1) Added Arnaud's reviewed-by and tested-by tags.
> 
> Applies cleanly on rproc-next (0cf17702d872)
> 
> [...]


Here is a summary with links:
  - [v6,1/9] remoteproc: Add new RPROC_DETACHED state
    https://git.kernel.org/andersson/remoteproc/c/e2e5c55eed8023ecfbf4c9b623ef7dec343d1845
  - [v6,2/9] remoteproc: Add new attach() remoteproc operation
    https://git.kernel.org/andersson/remoteproc/c/a6a4f2857524007848f7957af432cddb4d43b593
  - [v6,3/9] remoteproc: Introducing function rproc_attach()
    https://git.kernel.org/andersson/remoteproc/c/d848a4819d858973952de181314de6d05512fb98
  - [v6,4/9] remoteproc: Introducing function rproc_actuate()
    https://git.kernel.org/andersson/remoteproc/c/fdf0e00ed646fc94ab27e7d46fac983b1533a761
  - [v6,5/9] remoteproc: Introducing function rproc_validate()
    https://git.kernel.org/andersson/remoteproc/c/88d3a1360755b7dd88a737ef2cd966a54c932682
  - [v6,6/9] remoteproc: Refactor function rproc_boot()
    https://git.kernel.org/andersson/remoteproc/c/0f9dc562b721aa1c0190ffe9f32aa0fcd7b8f2e8
  - [v6,7/9] remoteproc: Refactor function rproc_trigger_auto_boot()
    https://git.kernel.org/andersson/remoteproc/c/e3d2193959824e2119996fe361f92b34750de2b0
  - [v6,8/9] remoteproc: Refactor function rproc_free_vring()
    https://git.kernel.org/andersson/remoteproc/c/4d3ebb3b99905e0e1c83b320764495f5fc3f93fe
  - [v6,9/9] remoteproc: Properly handle firmware name when attaching
    https://git.kernel.org/andersson/remoteproc/c/4a4dca1941fedc1b02635ff0b4ed51b9857d0382

You are awesome, thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/pwbot

^ permalink raw reply

* Re: [PATCH] remoteproc: qcom_q6v5_mss: Monitor MSS_STATUS for boot completion
From: patchwork-bot+linux-remoteproc @ 2020-07-18  0:20 UTC (permalink / raw)
  To: Sibi Sankar; +Cc: linux-remoteproc
In-Reply-To: <20200716120514.21588-1-sibis@codeaurora.org>

Hello:

This patch was applied to andersson/remoteproc.git (refs/heads/for-next).

On Thu, 16 Jul 2020 17:35:14 +0530 you wrote:
> On secure devices there exists a race condition which could lock the MSS
> CONFIG AHB bus thus preventing access to BOOT_STATUS register during SSR.
> Switch to polling the MSS_STATUS register with an additional 10 us delay
> to reliably track boot completion.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> 
> [...]


Here is a summary with links:
  - remoteproc: qcom_q6v5_mss: Monitor MSS_STATUS for boot completion
    https://git.kernel.org/andersson/remoteproc/c/4e6751a1cfab85b7a1c054cf3d55f12322e1ee3b

You are awesome, thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/pwbot

^ permalink raw reply

* Re: [PATCH] remoteproc: qcom: pil-info: Fix shift overflow
From: patchwork-bot+linux-remoteproc @ 2020-07-18  0:20 UTC (permalink / raw)
  To: Bjorn Andersson; +Cc: linux-remoteproc
In-Reply-To: <20200716054817.157608-1-bjorn.andersson@linaro.org>

Hello:

This patch was applied to andersson/remoteproc.git (refs/heads/for-next).

On Wed, 15 Jul 2020 22:48:17 -0700 you wrote:
> On platforms with 32-bit phys_addr_t the shift to get the upper word of
> the base address of the memory region is invalid. Cast the base to 64
> bit to resolv this.
> 
> Fixes: 549b67da660d ("remoteproc: qcom: Introduce helper to store pil info in IMEM")
> Reported-by: Lee Jones <lee.jones@linaro.org>
> Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> 
> [...]


Here is a summary with links:
  - remoteproc: qcom: pil-info: Fix shift overflow
    https://git.kernel.org/andersson/remoteproc/c/90ec257c380ebdcebf332b698f3e809cd1157202

You are awesome, thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/pwbot

^ permalink raw reply

* [GIT PULL FOR v5.9] Xilinx ZynqMP DisplayPort Subsystem driver
From: Laurent Pinchart @ 2020-07-18  0:17 UTC (permalink / raw)
  To: dri-devel; +Cc: Vinod Koul

Hi Dave, Daniel,

The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git tags/drm-xilinx-dpsub-20200718

for you to fetch changes up to d76271d22694e874ed70791702db9252ffe96a4c:

  drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem (2020-07-18 02:59:16 +0300)

The tag is based on the topic/xilinx branch from Vinod's dmaengine tree,
which contains required dependencies. That branch is itself based on
v5.8-rc1, and has been merged in the dmaengine -next branch, scheduled
for v5.9. I have verified that it doesn't conflict with drm-next.

----------------------------------------------------------------
Xilinx ZynqMP DisplayPort Subsystem driver

----------------------------------------------------------------
Hyun Kwon (3):
      dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver
      dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings
      drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem

Laurent Pinchart (2):
      dt: bindings: dma: xilinx: dpdma: DT bindings for Xilinx DPDMA
      dmaengine: Add support for repeating transactions

 .../display/xlnx/xlnx,zynqmp-dpsub.yaml         |  174 ++
 .../bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml  |   68 +
 Documentation/driver-api/dmaengine/client.rst   |    4 +-
 Documentation/driver-api/dmaengine/provider.rst |   49 +
 MAINTAINERS                                     |   18 +
 drivers/dma/Kconfig                             |   10 +
 drivers/dma/xilinx/Makefile                     |    1 +
 drivers/dma/xilinx/xilinx_dpdma.c               | 1533 +++++++++++++++
 drivers/gpu/drm/Kconfig                         |    2 +
 drivers/gpu/drm/Makefile                        |    1 +
 drivers/gpu/drm/xlnx/Kconfig                    |   13 +
 drivers/gpu/drm/xlnx/Makefile                   |    2 +
 drivers/gpu/drm/xlnx/zynqmp_disp.c              | 1697 ++++++++++++++++
 drivers/gpu/drm/xlnx/zynqmp_disp.h              |   42 +
 drivers/gpu/drm/xlnx/zynqmp_disp_regs.h         |  201 ++
 drivers/gpu/drm/xlnx/zynqmp_dp.c                | 1734 +++++++++++++++++
 drivers/gpu/drm/xlnx/zynqmp_dp.h                |   27 +
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c             |  322 +++
 drivers/gpu/drm/xlnx/zynqmp_dpsub.h             |   54 +
 include/dt-bindings/dma/xlnx-zynqmp-dpdma.h     |   16 +
 include/linux/dmaengine.h                       |   17 +
 21 files changed, 5984 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
 create mode 100644 Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
 create mode 100644 drivers/dma/xilinx/xilinx_dpdma.c
 create mode 100644 drivers/gpu/drm/xlnx/Kconfig
 create mode 100644 drivers/gpu/drm/xlnx/Makefile
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.h
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp_regs.h
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.h
 create mode 100644 include/dt-bindings/dma/xlnx-zynqmp-dpdma.h

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.