* 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.