* Re: ✓ Fi.CI.BAT: success for Display uncore prep patches (rev2)
From: Tvrtko Ursulin @ 2019-06-20 15:41 UTC (permalink / raw)
To: intel-gfx, Patchwork, Daniele Ceraolo Spurio
In-Reply-To: <20190620014410.18135.63392@emeril.freedesktop.org>
On 20/06/2019 02:44, Patchwork wrote:
> == Series Details ==
>
> Series: Display uncore prep patches (rev2)
> URL : https://patchwork.freedesktop.org/series/62232/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6312 -> Patchwork_13357
> ====================================================
>
> Summary
> -------
>
> **SUCCESS**
>
> No regressions found.
>
> External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/
>
> Known issues
> ------------
>
> Here are the changes found in Patchwork_13357 that come from known issues:
>
> ### IGT changes ###
>
> #### Issues hit ####
>
> * igt@gem_exec_suspend@basic-s3:
> - fi-cfl-8109u: [PASS][1] -> [FAIL][2] ([fdo#103375])
> [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-cfl-8109u/igt@gem_exec_suspend@basic-s3.html
> [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-cfl-8109u/igt@gem_exec_suspend@basic-s3.html
>
> * igt@i915_selftest@live_hangcheck:
> - fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569])
> [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
> [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
>
>
> #### Possible fixes ####
>
> * igt@gem_exec_suspend@basic-s3:
> - fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
> [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
> [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
>
> * igt@i915_selftest@live_contexts:
> - fi-skl-gvtdvm: [DMESG-FAIL][7] ([fdo#110235]) -> [PASS][8]
> [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
> [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
>
> * igt@kms_chamelium@hdmi-hpd-fast:
> - fi-kbl-7500u: [FAIL][9] ([fdo#109485]) -> [PASS][10]
> [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
> [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
>
> * igt@kms_frontbuffer_tracking@basic:
> - fi-icl-u2: [FAIL][11] ([fdo#103167]) -> [PASS][12]
> [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html
> [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html
>
>
> [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
> [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
> [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
> [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
> [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
> [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
> [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
>
>
> Participating hosts (49 -> 46)
> ------------------------------
>
> Additional (5): fi-cml-u2 fi-bxt-j4205 fi-gdg-551 fi-icl-dsi fi-cml-u
> Missing (8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
>
>
> Build changes
> -------------
>
> * Linux: CI_DRM_6312 -> Patchwork_13357
>
> CI_DRM_6312: 034e3ac6a2d180d188da927388b60c7e62c5655b @ git://anongit.freedesktop.org/gfx-ci/linux
> IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_13357: 776298c3ec6b6f35479ec3ca194c3f11e809b916 @ git://anongit.freedesktop.org/gfx-ci/linux
>
>
> == Linux commits ==
>
> 776298c3ec6b drm/i915/gvt: decouple check_vgpu() from uncore_init()
> 6186c2ceab1a drm/i915: dynamically allocate forcewake domains
> 7c1c30e3557c drm/i915: skip forcewake actions on forcewake-less uncore
> a33912a9c7bb drm/i915: kill uncore_to_i915
> 64e9e429a365 drm/i915: kill uncore_sanitize
> d925fdfca22c drm/i915: use vfuncs for reg_read/write_fw_domains
Pushed, thanks for patches and reviews.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2 2/2] ssh: Add interface ssh_search_dir
From: Dominick Grift @ 2019-06-20 15:40 UTC (permalink / raw)
To: Alexander Miroshnichenko, selinux-refpolicy
In-Reply-To: <20190620152731.GD2647@brutus.lan>
[-- Attachment #1: Type: text/plain, Size: 3225 bytes --]
On Thu, Jun 20, 2019 at 05:27:31PM +0200, Dominick Grift wrote:
> On Thu, Jun 20, 2019 at 06:05:57PM +0300, Alexander Miroshnichenko wrote:
> > On четверг, 20 июня 2019 г. 17:50:11 MSK, Dominick Grift wrote:
> > > On Thu, Jun 20, 2019 at 05:41:38PM +0300, Alexander Miroshnichenko wrote:
> > > > Create interface ssh_search_dir to allow ssh_server search for keys
> > > > in non-standard location.
> > > >
> > > > Signed-off-by: Alexander Miroshnichenko <alex@millerson.name>
> > > > ---
> > > > policy/modules/services/ssh.if | 18 ++++++++++++++++++
> > > > 1 file changed, 18 insertions(+)
> > > >
> > > > diff --git a/policy/modules/services/ssh.if
> > > > b/policy/modules/services/ssh.if
> > > > index 0941f133711e..51c64ded00c4 100644
> > > > --- a/policy/modules/services/ssh.if
> > > > +++ b/policy/modules/services/ssh.if
> > > > @@ -680,6 +680,24 @@ interface(`ssh_agent_exec',`
> > > > can_exec($1, ssh_agent_exec_t)
> > > > ')
> > > > +########################################
> > > > +## <summary>
> > > > +## Search for keys in non-standard location
> > > > +## </summary>
> > > > +## <param name="domain">
> > > > +## <summary>
> > > > +## Domain allowed access.
> > > > +## </summary>
> > > > +## </param>
> > > > +#
> > > > +interface(`ssh_search_dir',`
> > > > + gen_require(`
> > > > + type sshd_t;
> > > > + ')
> > > > +
> > > > + allow sshd_t $1:dir search_dir_perms;
> > >
> > > This is generally not allowed. The caller should generally be the source.
> > > Regardless of the above. Keys should be in user home directories. I
> > > wonder what specific scenario prompted you to propose this interface?
> >
> > GIT hosting software like gitolite/gitosis/gitea manage users ssh keys and
> > store them own location like /var/lib/gitolite/.ssh . /var/lib/gitolite have
> > gitosis_var_lib_t type, /var/lib/gitolite/.ssh have gitosis_ssh_home_t type
> > (in patched policy which I want to submit).
> > If sshd does not have { search getattr } permissions to full path to ssh key
> > user fail to login.
> > Can you propose corret way to give such permissions to multiple policies?
> > It is incorrect to label /var/lib/gitolite as user_home_dir_t type, IMHO.
>
> Yes this sucks. I would probably do the following instead:
>
> 1. echo "ignoredirs=/var/lib/gitolite" >> /etc/selinux/semanage.conf
> 2. semodule -B && restorecon -RvF /var/lib/gitolite
> 3. gitosis_read_lib_files(sshd_t)
>
> Dont bother with labeling /var/lib/gitolite/.ssh differently
But this is just what I would do (if were ever forced to use gitolite). Others may have different opinions.
>
> >
> > > > +')
> > > > +
> > > > ########################################
> > > > ## <summary>
> > > > ## Read ssh home directory content ...
> > >
> >
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* Re: [usb:usb-testing 46/46] drivers/usb//misc/adutux.c:375:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}'
From: Johan Hovold @ 2019-06-20 15:40 UTC (permalink / raw)
To: dmg; +Cc: linux-usb, Greg Kroah-Hartman
In-Reply-To: <87wohgs3lh.fsf@mn.cs.uvic.ca>
On Thu, Jun 20, 2019 at 08:01:30AM -0700, dmg wrote:
>
> kbuild test robot <lkp@intel.com> writes:
>
> [...]
> >
> > All warnings (new ones prefixed by >>):
> >
> > In file included from include/linux/printk.h:332:0,
> > from include/linux/kernel.h:15,
> > from drivers/usb//misc/adutux.c:19:
> > drivers/usb//misc/adutux.c: In function 'adu_read':
> >>> drivers/usb//misc/adutux.c:375:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Wformat=]
> > "%s : while, data_in_secondary=%lu, status=%d\n",
>
> I am not sure what is the best way to address this warning.
>
> size_t seems to be architecture dependent. On my computer (intel64)
> size_t is long unsigned int, but in this test it is int unsigned.
>
> Are there any suggestions on what is the best way to deal with this?
You should use %zu.
Johan
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH 0/9] hw/acpi: make build_madt arch agnostic
From: Igor Mammedov @ 2019-06-20 15:04 UTC (permalink / raw)
To: Wei Yang; +Cc: yang.zhong, ehabkost, mst, qemu-devel, Wei Yang, pbonzini, rth
In-Reply-To: <20190620141842.ijqwozpjrkccy7qx@master>
On Thu, 20 Jun 2019 14:18:42 +0000
Wei Yang <richard.weiyang@gmail.com> wrote:
> On Wed, Jun 19, 2019 at 11:04:40AM +0200, Igor Mammedov wrote:
> >On Wed, 19 Jun 2019 14:20:50 +0800
> >Wei Yang <richardw.yang@linux.intel.com> wrote:
> >
> >> On Tue, Jun 18, 2019 at 05:59:56PM +0200, Igor Mammedov wrote:
> >> >
> >> >On Mon, 13 May 2019 14:19:04 +0800
> >> >Wei Yang <richardw.yang@linux.intel.com> wrote:
> >> >
> >> >> Now MADT is highly depend in architecture and machine type and leaves
> >> >> duplicated code in different architecture. The series here tries to generalize
> >> >> it.
> >> >>
> >> >> MADT contains one main table and several sub tables. These sub tables are
> >> >> highly related to architecture. Here we introduce one method to make it
> >> >> architecture agnostic.
> >> >>
> >> >> * each architecture define its sub-table implementation function in madt_sub
> >> >> * introduces struct madt_input to collect sub table information and pass to
> >> >> build_madt
> >> >>
> >> >> By doing so, each architecture could prepare its own sub-table implementation
> >> >> and madt_input. And keep build_madt architecture agnostic.
> >> >
> >> >I've skimmed over patches, and to me it looks mostly as code movement
> >> >without apparent benefits and probably a bit more complex than what we have now
> >> >(it might be ok cost if it simplifies MADT support for other boards).
> >> >
> >> >Before I do line by line review could you demonstrate what effect new way
> >> >to build MADT would have on arm/virt and i386/virt (from NEMU). So it would be
> >> >possible to estimate net benefits from new approach?
> >> >(PS: it doesn't have to be patches ready for merging, just a dirty hack
> >> >that would demonstrate adding MADT for new board using mad_sub[])
> >> >
> >>
> >> Per APIC spec 5.2.12, MADT contains a *main* table and several *sub* tables
> >> (Interrupt Controllere), so the idea is give a callback hook in
> >> AcpiDeviceIfClass for each table, including *main* and *sub* table.
> >>
> >> Current AcpiDeviceIfClass has one callback pc_madt_cpu_entry for some *sub*
> >> tables, after replacing the AcpiDeviceIfClass will look like this:
> >>
> >> typedef struct AcpiDeviceIfClass {
> >> /* <private> */
> >> InterfaceClass parent_class;
> >>
> >> /* <public> */
> >> void (*ospm_status)(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
> >> void (*send_event)(AcpiDeviceIf *adev, AcpiEventStatusBits ev);
> >> - void (*madt_cpu)(AcpiDeviceIf *adev, int uid,
> >> - const CPUArchIdList *apic_ids, GArray *entry);
> >> + madt_operation madt_main;
> >> + madt_operation *madt_sub;
> >> } AcpiDeviceIfClass;
> >>
> >> By doing so, each arch could have its own implementation for MADT.
> >>
> >> After this refactoring, build_madt could be simplified to:
> >>
> >> build_madt(GArray *table_data, BIOSLinker *linker, PCMachineState *pcms,
> >> struct madt_input *input)
> >> {
> >> ...
> >>
> >> if (adevc->madt_main) {
> >> adevc->madt_main(table_data, madt);
> >> }
> >>
> >> for (i = 0; ; i++) {
> >> sub_id = input[i].sub_id;
> >> if (sub_id == ACPI_APIC_RESERVED) {
> >> break;
> >> }
> >> opaque = input[i].opaque;
> >> adevc->madt_sub[sub_id](table_data, opaque);
> >> }
> >>
> >> ...
> >> }
> >>
> >> input is a list of data necessary to build *sub* table. Its details is also
> >> arch dependent.
> >I've got general idea reading patches in this series.
> >As I've mentioned before it's hard to generalize MADT since it
> >mostly contains entries unique for target/board.
> >Goal here isn't generalizing at any cost, but rather find out
> >if there is enough common code to justify generalization
> >and if it allows us to reduce code duplication and simplify.
> >
> >> For following new arch, what it need to do is prepare the input array and
> >> implement necessary *main*/*sub* table callbacks.
> >What I'd like to see is the actual patch that does this,
> >to see if it has any merit and to compare to the current
> >approach.
>
> I didn't get some idea about your approach. Would you mind sharing more light?
With current approach, 'each board' has its own MADT build routine.
Considering that there is very little to share between different
implementations it might be ok.
This series just add extra data structure for board to populate
and a bunch of callbacks for every record type. Essentially all
the code we have now is still there. It was just moved elsewhere
and made available via callbacks.
This series touches only pc/q35 machines and it's not apparent
to me why it's any better than what we have now.
^ permalink raw reply
* ✗ Fi.CI.IGT: failure for series starting with drm/i915/execlists: Preempt-to-busy (rev2)
From: Patchwork @ 2019-06-20 15:38 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20190620070559.30076-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with drm/i915/execlists: Preempt-to-busy (rev2)
URL : https://patchwork.freedesktop.org/series/62431/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6312_full -> Patchwork_13361_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_13361_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_13361_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_13361_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_await@wide-contexts:
- shard-kbl: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl4/igt@gem_exec_await@wide-contexts.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-kbl1/igt@gem_exec_await@wide-contexts.html
### Piglit changes ###
#### Possible regressions ####
* spec@arb_shader_image_load_store@shader-mem-barrier (NEW):
- pig-glk-j5005: NOTRUN -> [FAIL][3] +2 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/pig-glk-j5005/spec@arb_shader_image_load_store@shader-mem-barrier.html
- pig-skl-6260u: NOTRUN -> [FAIL][4]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/pig-skl-6260u/spec@arb_shader_image_load_store@shader-mem-barrier.html
New tests
---------
New tests have been introduced between CI_DRM_6312_full and Patchwork_13361_full:
### New Piglit tests (3) ###
* spec@arb_shader_image_load_store@shader-mem-barrier:
- Statuses : 2 fail(s)
- Exec time: [0.13, 0.18] s
* spec@ext_transform_feedback@order arrays points:
- Statuses : 1 fail(s)
- Exec time: [0.11] s
* spec@glsl-1.30@execution@fs-execution-ordering:
- Statuses : 1 fail(s)
- Exec time: [0.52] s
Known issues
------------
Here are the changes found in Patchwork_13361_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_eio@unwedge-stress:
- shard-snb: [PASS][5] -> [FAIL][6] ([fdo#109661]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb5/igt@gem_eio@unwedge-stress.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-snb5/igt@gem_eio@unwedge-stress.html
* igt@gem_eio@wait-wedge-10ms:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +1 similar issue
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl7/igt@gem_eio@wait-wedge-10ms.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-apl3/igt@gem_eio@wait-wedge-10ms.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#110854])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb1/igt@gem_exec_balancer@smoke.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb5/igt@gem_exec_balancer@smoke.html
* igt@gem_persistent_relocs@forked-faulting-reloc-thrashing:
- shard-snb: [PASS][11] -> [DMESG-WARN][12] ([fdo#110789] / [fdo#110913 ])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb6/igt@gem_persistent_relocs@forked-faulting-reloc-thrashing.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-snb4/igt@gem_persistent_relocs@forked-faulting-reloc-thrashing.html
* igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl1/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-kbl1/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
* igt@gem_tiled_swapping@non-threaded:
- shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108686])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl4/igt@gem_tiled_swapping@non-threaded.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-kbl3/igt@gem_tiled_swapping@non-threaded.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-snb: [PASS][17] -> [DMESG-WARN][18] ([fdo#110913 ])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@gem_userptr_blits@sync-unmap-cycles.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-snb7/igt@gem_userptr_blits@sync-unmap-cycles.html
* igt@i915_selftest@live_hangcheck:
- shard-snb: [PASS][19] -> [INCOMPLETE][20] ([fdo#105411])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@i915_selftest@live_hangcheck.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-snb7/igt@i915_selftest@live_hangcheck.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [PASS][21] -> [FAIL][22] ([fdo#105767])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw7/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-hsw8/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: [PASS][23] -> [FAIL][24] ([fdo#105363])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk8/igt@kms_flip@2x-flip-vs-expired-vblank.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank.html
* igt@kms_flip@flip-vs-suspend:
- shard-skl: [PASS][25] -> [INCOMPLETE][26] ([fdo#109507])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl8/igt@kms_flip@flip-vs-suspend.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-skl8/igt@kms_flip@flip-vs-suspend.html
- shard-hsw: [PASS][27] -> [INCOMPLETE][28] ([fdo#103540])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw5/igt@kms_flip@flip-vs-suspend.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-hsw1/igt@kms_flip@flip-vs-suspend.html
- shard-glk: [PASS][29] -> [INCOMPLETE][30] ([fdo#103359] / [k.org#198133])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk9/igt@kms_flip@flip-vs-suspend.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-glk4/igt@kms_flip@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
- shard-iclb: [PASS][31] -> [FAIL][32] ([fdo#103167]) +7 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt:
- shard-hsw: [PASS][33] -> [SKIP][34] ([fdo#109271]) +7 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-hsw1/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-skl: [PASS][35] -> [FAIL][36] ([fdo#103167])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-skl10/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- shard-skl: [PASS][37] -> [FAIL][38] ([fdo#103191])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl3/igt@kms_pipe_crc_basic@hang-read-crc-pipe-c.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-skl9/igt@kms_pipe_crc_basic@hang-read-crc-pipe-c.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-apl: [PASS][39] -> [DMESG-WARN][40] ([fdo#108566]) +2 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-apl5/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [PASS][41] -> [FAIL][42] ([fdo#108145]) +1 similar issue
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][43] -> [SKIP][44] ([fdo#109642])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb7/igt@kms_psr2_su@frontbuffer.html
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: [PASS][45] -> [SKIP][46] ([fdo#109441]) +1 similar issue
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb3/igt@kms_psr@psr2_cursor_blt.html
#### Possible fixes ####
* igt@gem_eio@wait-10ms:
- shard-apl: [DMESG-WARN][47] ([fdo#110913 ]) -> [PASS][48] +1 similar issue
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl8/igt@gem_eio@wait-10ms.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-apl7/igt@gem_eio@wait-10ms.html
* igt@gem_exec_schedule@semaphore-resolve:
- shard-skl: [FAIL][49] ([fdo#110519] / [fdo#110946]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl6/igt@gem_exec_schedule@semaphore-resolve.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-skl7/igt@gem_exec_schedule@semaphore-resolve.html
- shard-kbl: [FAIL][51] ([fdo#110519] / [fdo#110946]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl2/igt@gem_exec_schedule@semaphore-resolve.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-kbl3/igt@gem_exec_schedule@semaphore-resolve.html
- shard-apl: [FAIL][53] ([fdo#110519]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl1/igt@gem_exec_schedule@semaphore-resolve.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-apl1/igt@gem_exec_schedule@semaphore-resolve.html
- shard-glk: [FAIL][55] ([fdo#110519] / [fdo#110946]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk7/igt@gem_exec_schedule@semaphore-resolve.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-glk9/igt@gem_exec_schedule@semaphore-resolve.html
- shard-iclb: [FAIL][57] ([fdo#110519] / [fdo#110946]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb5/igt@gem_exec_schedule@semaphore-resolve.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb4/igt@gem_exec_schedule@semaphore-resolve.html
* igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-snb: [DMESG-WARN][59] ([fdo#110789] / [fdo#110913 ]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb4/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-snb6/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
* igt@i915_selftest@live_hangcheck:
- shard-iclb: [INCOMPLETE][61] ([fdo#107713] / [fdo#108569]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb1/igt@i915_selftest@live_hangcheck.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb5/igt@i915_selftest@live_hangcheck.html
* igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge:
- shard-snb: [SKIP][63] ([fdo#109271] / [fdo#109278]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-snb5/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [FAIL][65] ([fdo#104873]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk8/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-glk1/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [SKIP][67] ([fdo#109349]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb7/igt@kms_dp_dsc@basic-dsc-enable-edp.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite:
- shard-hsw: [SKIP][69] ([fdo#109271]) -> [PASS][70] +33 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw1/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-hsw4/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render:
- shard-iclb: [FAIL][71] ([fdo#103167]) -> [PASS][72] +6 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-apl: [DMESG-WARN][73] ([fdo#108566]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl5/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-apl6/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-skl: [INCOMPLETE][75] ([fdo#104108]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-skl8/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
* igt@kms_plane@plane-panning-bottom-right-pipe-b-planes:
- shard-snb: [SKIP][77] ([fdo#109271]) -> [PASS][78] +1 similar issue
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-snb5/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
* igt@kms_psr@no_drrs:
- shard-iclb: [FAIL][79] ([fdo#108341]) -> [PASS][80]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb1/igt@kms_psr@no_drrs.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb5/igt@kms_psr@no_drrs.html
* igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [SKIP][81] ([fdo#109441]) -> [PASS][82] +1 similar issue
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
* igt@kms_setmode@basic:
- shard-kbl: [FAIL][83] ([fdo#99912]) -> [PASS][84]
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl1/igt@kms_setmode@basic.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-kbl1/igt@kms_setmode@basic.html
* igt@kms_sysfs_edid_timing:
- shard-iclb: [FAIL][85] ([fdo#100047]) -> [PASS][86]
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-iclb2/igt@kms_sysfs_edid_timing.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/shard-iclb4/igt@kms_sysfs_edid_timing.html
[fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661
[fdo#110519]: https://bugs.freedesktop.org/show_bug.cgi?id=110519
[fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
[fdo#110946]: https://bugs.freedesktop.org/show_bug.cgi?id=110946
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* Linux: CI_DRM_6312 -> Patchwork_13361
CI_DRM_6312: 034e3ac6a2d180d188da927388b60c7e62c5655b @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13361: bfa0c571526c8b843afc7e42fe124e39ff9d81d3 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 2/2] arm64: dts: agilex/stratix10: Add reset properties for DMA
From: Dinh Nguyen @ 2019-06-20 15:37 UTC (permalink / raw)
To: robh+dt, mark.rutland; +Cc: dinguyen, linux-arm-kernel, devicetree
In-Reply-To: <20190620153732.26738-1-dinguyen@kernel.org>
Add both the reset and reset-ocp properties for the DMA node on the
Stratix10 and Agilex platforms.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 2 ++
arch/arm64/boot/dts/intel/socfpga_agilex.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index a781e699a538..5db9ff05fc33 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -335,6 +335,8 @@
#dma-requests = <32>;
clocks = <&clkmgr STRATIX10_L4_MAIN_CLK>;
clock-names = "apb_pclk";
+ resets = <&rst DMA_RESET>, <&rst DMA_OCP_RESET>;
+ reset-names = "dma", "dma-ocp";
};
rst: rstmgr@ffd11000 {
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
index e4ceb3a73c81..36abc25320a8 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
@@ -249,6 +249,8 @@
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
+ resets = <&rst DMA_RESET>, <&rst DMA_OCP_RESET>;
+ reset-names = "dma", "dma-ocp";
};
rst: rstmgr@ffd11000 {
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/2] ssh: Add interface ssh_search_dir
From: Alexander Miroshnichenko @ 2019-06-20 15:38 UTC (permalink / raw)
To: Dominick Grift; +Cc: selinux-refpolicy
In-Reply-To: <20190620152731.GD2647@brutus.lan>
On четверг, 20 июня 2019 г. 18:27:31 MSK, Dominick Grift wrote:
> On Thu, Jun 20, 2019 at 06:05:57PM +0300, Alexander Miroshnichenko wrote:
>> On четверг, 20 июня 2019 г. 17:50:11 MSK, Dominick Grift wrote: ...
>
> Yes this sucks. I would probably do the following instead:
>
> 1. echo "ignoredirs=/var/lib/gitolite" >> /etc/selinux/semanage.conf
> 2. semodule -B && restorecon -RvF /var/lib/gitolite
> 3. gitosis_read_lib_files(sshd_t)
I can't use sshd_t in another policy without require statement.
Or I need to add gitosis_read_lib_files(sshd_t) to ssh.te policy file.
All 3 steps are ugly comparing with new ssh_search_dir() interface.
Why such restrictions where caller must be the source for interface? It is
not flexible.
>
> Dont bother with labeling /var/lib/gitolite/.ssh differently
>
>> ...
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v5 2/2] ati-vga: Implement DDC and EDID info from monitor
From: Gerd Hoffmann @ 2019-06-20 15:09 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Corey Minyard, qemu-devel
In-Reply-To: <046ddebb7ec8db48c4e877ee444ec1c41e385a74.1561028123.git.balaton@eik.bme.hu>
On Thu, Jun 20, 2019 at 12:55:23PM +0200, BALATON Zoltan wrote:
> This adds DDC support to ati-vga and connects i2c-ddc to it. This
> allows at least MacOS with an ATI ndrv, Linux radeonfb and MorphOS to
linux radeonfb is rv100 only, and aty128fb has no i2c support.
Do MacOS and MorphOS have working edid with both card variants?
> + case GPIO_MONID ... GPIO_MONID + 3:
> + /* FIXME What does Radeon have here? */
> + if (s->dev_id == PCI_DEVICE_ID_ATI_RAGE128_PF) {
> + /* Rage128p accesses DDC used to get EDID on these pins */
> + ati_reg_write_offs(&s->regs.gpio_monid,
> + addr - GPIO_MONID, data, size);
> + if ((s->regs.gpio_monid & BIT(25)) &&
Extra enable bit, ok.
> + addr <= GPIO_MONID + 2 && addr + size > GPIO_MONID + 2) {
Hmm, isn't this just "addr == GPIO_MONID + 2" ?
> + s->regs.gpio_monid = ati_i2c(s->bbi2c, s->regs.gpio_monid, 1);
So all i2c bits are shifted by one compared to rv100, correct?
cheers,
Gerd
^ permalink raw reply
* [PATCH 1/2] ARM: dts: socfpga: add reset properties for DMA
From: Dinh Nguyen @ 2019-06-20 15:37 UTC (permalink / raw)
To: robh+dt, mark.rutland; +Cc: dinguyen, linux-arm-kernel, devicetree
Add both the reset and reset-ocp properties for the DMA node on Arria10.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm/boot/dts/socfpga_arria10.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 20af1543819a..26c157b91189 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -68,6 +68,8 @@
#dma-requests = <32>;
clocks = <&l4_main_clk>;
clock-names = "apb_pclk";
+ resets = <&rst DMA_RESET>, <&rst DMA_OCP_RESET>;
+ reset-names = "dma", "dma-ocp";
};
};
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 4/9] blkcg: implement REQ_CGROUP_PUNT
From: Jan Kara @ 2019-06-20 15:37 UTC (permalink / raw)
To: Tejun Heo
Cc: dsterba, clm, josef, axboe, jack, linux-btrfs, linux-kernel,
linux-block, kernel-team
In-Reply-To: <20190615182453.843275-5-tj@kernel.org>
On Sat 15-06-19 11:24:48, Tejun Heo wrote:
> When a shared kthread needs to issue a bio for a cgroup, doing so
> synchronously can lead to priority inversions as the kthread can be
> trapped waiting for that cgroup. This patch implements
> REQ_CGROUP_PUNT flag which makes submit_bio() punt the actual issuing
> to a dedicated per-blkcg work item to avoid such priority inversions.
>
> This will be used to fix priority inversions in btrfs compression and
> should be generally useful as we grow filesystem support for
> comprehensive IO control.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reviewed-by: Josef Bacik <josef@toxicpanda.com>
> Cc: Chris Mason <clm@fb.com>
...
> +bool __blkcg_punt_bio_submit(struct bio *bio)
> +{
> + struct blkcg_gq *blkg = bio->bi_blkg;
> +
> + /* consume the flag first */
> + bio->bi_opf &= ~REQ_CGROUP_PUNT;
> +
> + /* never bounce for the root cgroup */
> + if (!blkg->parent)
> + return false;
> +
> + spin_lock_bh(&blkg->async_bio_lock);
> + bio_list_add(&blkg->async_bios, bio);
> + spin_unlock_bh(&blkg->async_bio_lock);
> +
> + queue_work(blkcg_punt_bio_wq, &blkg->async_bio_work);
> + return true;
> +}
> +
So does this mean that if there is some inode with lots of dirty data for a
blkcg that is heavily throttled, that blkcg can occupy a ton of workers all
being throttled in submit_bio()? Or what is constraining a number of
workers one blkcg can consume?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH 2/2] arm64: dts: agilex/stratix10: Add reset properties for DMA
From: Dinh Nguyen @ 2019-06-20 15:37 UTC (permalink / raw)
To: robh+dt, mark.rutland; +Cc: dinguyen, linux-arm-kernel, devicetree
In-Reply-To: <20190620153732.26738-1-dinguyen@kernel.org>
Add both the reset and reset-ocp properties for the DMA node on the
Stratix10 and Agilex platforms.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 2 ++
arch/arm64/boot/dts/intel/socfpga_agilex.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index a781e699a538..5db9ff05fc33 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -335,6 +335,8 @@
#dma-requests = <32>;
clocks = <&clkmgr STRATIX10_L4_MAIN_CLK>;
clock-names = "apb_pclk";
+ resets = <&rst DMA_RESET>, <&rst DMA_OCP_RESET>;
+ reset-names = "dma", "dma-ocp";
};
rst: rstmgr@ffd11000 {
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
index e4ceb3a73c81..36abc25320a8 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
@@ -249,6 +249,8 @@
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
+ resets = <&rst DMA_RESET>, <&rst DMA_OCP_RESET>;
+ reset-names = "dma", "dma-ocp";
};
rst: rstmgr@ffd11000 {
--
2.20.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: socfpga: add reset properties for DMA
From: Dinh Nguyen @ 2019-06-20 15:37 UTC (permalink / raw)
To: robh+dt, mark.rutland; +Cc: dinguyen, linux-arm-kernel, devicetree
Add both the reset and reset-ocp properties for the DMA node on Arria10.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm/boot/dts/socfpga_arria10.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 20af1543819a..26c157b91189 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -68,6 +68,8 @@
#dma-requests = <32>;
clocks = <&l4_main_clk>;
clock-names = "apb_pclk";
+ resets = <&rst DMA_RESET>, <&rst DMA_OCP_RESET>;
+ reset-names = "dma", "dma-ocp";
};
};
--
2.20.0
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v3 05/10] hw/riscv: Replace global smp variables with machine smp properties
From: Eduardo Habkost @ 2019-06-20 14:52 UTC (permalink / raw)
To: Like Xu
Cc: Peter Maydell, qemu-trivial, qemu-devel, Dr . David Alan Gilbert,
Alistair Francis, Igor Mammedov
In-Reply-To: <20190518205428.90532-6-like.xu@linux.intel.com>
On Sun, May 19, 2019 at 04:54:23AM +0800, Like Xu wrote:
> The global smp variables in riscv are replaced with smp machine properties.
>
> A local variable of the same name would be introduced in the declaration
> phase if it's used widely in the context OR replace it on the spot if it's
> only used once. No semantic changes.
>
> Signed-off-by: Like Xu <like.xu@linux.intel.com>
> ---
> hw/riscv/sifive_e.c | 6 ++++--
> hw/riscv/sifive_plic.c | 3 +++
> hw/riscv/sifive_u.c | 6 ++++--
> hw/riscv/spike.c | 2 ++
> hw/riscv/virt.c | 1 +
> 5 files changed, 14 insertions(+), 4 deletions(-)
This was incomplete, I had to apply the following fixup.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/riscv/spike.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index 9e95f2c13c..d91d49dcae 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -172,6 +172,7 @@ static void spike_board_init(MachineState *machine)
MemoryRegion *main_mem = g_new(MemoryRegion, 1);
MemoryRegion *mask_rom = g_new(MemoryRegion, 1);
int i;
+ unsigned int smp_cpus = machine->smp.cpus;
/* Initialize SOC */
object_initialize_child(OBJECT(machine), "soc", &s->soc, sizeof(s->soc),
--
2.18.0.rc1.1.g3f1ff2140
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 1/9] bpf: track spill/fill of constants
From: Alexei Starovoitov @ 2019-06-20 15:37 UTC (permalink / raw)
To: John Fastabend
Cc: Alexei Starovoitov, David S. Miller, Daniel Borkmann,
Network Development, bpf, Kernel Team
In-Reply-To: <5d0b13c990eaa_21bb2acd7a54c5b4a0@john-XPS-13-9370.notmuch>
On Wed, Jun 19, 2019 at 10:04 PM John Fastabend
<john.fastabend@gmail.com> wrote:
>
> working my way through the series now, but for this patch
>
> Acked-by: John Fastabend <john.fastabend@gmail.com>
Thanks a lot for review!
It's landed now, but if you find anything I'll send
follow up patches.
Which I plan to do anyway for few things in backtracking logic.
^ permalink raw reply
* Re: [PATCH RESEND] mmc: core: try to use an id from the devicetree
From: Ulf Hansson @ 2019-06-20 15:37 UTC (permalink / raw)
To: Lubomir Rintel
Cc: linux-mmc@vger.kernel.org, Linux Kernel Mailing List,
Doug Anderson
In-Reply-To: <20190620152432.1408278-1-lkundrak@v3.sk>
+ Doug
On Thu, 20 Jun 2019 at 17:24, Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> If there's a mmc* alias in the device tree, take the device number from
> it, so that we end up with a device name that matches the alias.
Lots of people would be happy if I queue something along the lines of
what you propose. I am not really having any big problems with it, but
I am reluctant to queue it because of other peoples quite strong
opinions [1] that have been expressed in regards to this already.
Kind regards
Uffe
[1]
https://www.spinics.net/lists/devicetree-spec/msg00254.html
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> drivers/mmc/core/host.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 6a51f7a06ce7..4733ddb894da 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -411,7 +411,12 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
> /* scanning will be enabled when we're ready */
> host->rescan_disable = 1;
>
> - err = ida_simple_get(&mmc_host_ida, 0, 0, GFP_KERNEL);
> + /* prefer an alias */
> + err = of_alias_get_id(dev->of_node, "mmc");
> + if (err < 0)
> + err = 0;
> +
> + err = ida_simple_get(&mmc_host_ida, err, 0, GFP_KERNEL);
> if (err < 0) {
> kfree(host);
> return NULL;
> --
> 2.21.0
>
^ permalink raw reply
* Re: [CI v3 11/33] drm/i915: Store backpointer to intel_gt in the engine
From: Chris Wilson @ 2019-06-20 15:36 UTC (permalink / raw)
To: Intel-gfx, Tvrtko Ursulin
In-Reply-To: <20190620153136.26200-1-tvrtko.ursulin@linux.intel.com>
Quoting Tvrtko Ursulin (2019-06-20 16:31:36)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 82b7ace62d97..82fe6d5f08d4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -3290,6 +3290,7 @@ intel_execlists_create_virtual(struct i915_gem_context *ctx,
> return ERR_PTR(-ENOMEM);
>
> ve->base.i915 = ctx->i915;
> + ve->base.gt = siblings[0]->gt;
That poses an interesting dilemma:
if (siblings[n]->gt != ve->base.gt)
return -EINVAL?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/3] crypto: inside-secure - add support for PCI based FPGA development board
From: Antoine Tenart @ 2019-06-20 15:36 UTC (permalink / raw)
To: Pascal Van Leeuwen
Cc: Antoine Tenart, Pascal van Leeuwen, linux-crypto@vger.kernel.org,
herbert@gondor.apana.org.au, davem@davemloft.net
In-Reply-To: <AM6PR09MB352373E464F758B8D69C62B6D2E40@AM6PR09MB3523.eurprd09.prod.outlook.com>
Hi Pascal,
On Thu, Jun 20, 2019 at 02:47:30PM +0000, Pascal Van Leeuwen wrote:
> > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > On Wed, Jun 19, 2019 at 02:22:19PM +0000, Pascal Van Leeuwen wrote:
> > > > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > > > On Tue, Jun 18, 2019 at 07:56:23AM +0200, Pascal van Leeuwen wrote:
> > > > >
> > > > > /* Fallback to the old firmware location for the
> > > > > @@ -294,6 +291,9 @@ static int safexcel_hw_init(struct safexcel_crypto_priv *priv)
> > > > >
> > > > > + dev_info(priv->dev, "EIP(1)97 HW init: burst size %d beats, using %d pipe(s) and %d
> > > > ring(s)",
> > > > > + 16, priv->config.pes, priv->config.rings);
> > > >
> > > > Adding custom messages in the kernel log has to be done carefully.
> > > > Although it's not considered stable it could be difficult to rework
> > > > later on. Also, if all driver were to print custom messages the log
> > > > would be very hard to read. But you can also argue that a single message
> > > > when probing a driver is also done in other drivers.
> > > >
> > > Hmm ... don't know what the rules for logging are exactly, but from my
> > > perspective, I'm dealing with a zillion different HW configurations so
> > > some feedback whether the driver detected the *correct* HW parameters -
> > > or actually, whether I stuffed the correct image into my FPGA :o) - is
> > > very convenient to have. And not just for my local development, but also
> > > to debug deployments in the field at customer sites.
> >
> > I understand it can be convenient, it's just a matter of having a
> > logging message for you that will end up in many builds for many users.
> > They do not necessarily have the same needs. So it's a matter of
> > compromise, one or two messages at boot can be OK, more is likely to
> > become an issue.
> >
> OK, got it. So I have to stuff all my logging into one or two very long lines :-P
> (just kidding)
Hehe :-)
> > > > For this one particularly, the probe could fail later on. So if we were
> > > > to add this output, it should be done at the very end of the probe.
> > > >
> > > I'm in doubt about this one. I understand that you want to reduce the
> > > logging in that case, but at the same time that message can convey
> > > information as to WHY the probing fails later on ...
> >
> > If the drivers fails to probe, there will be other messages. In that
> > case is this one really needed? I'm not sure.
> >
> > > i.e. if it detects, say, 4 pipes on a device that, in fact, only has
> > > 2, then that may be the very reason for the FW init to fail later on.
> >
> > In case of failure you'll need anyway to debug and understand what's
> > going on. By adding new prints, or enabling debugging messages.
> >
> If it fails for me locally, I can do that. If it somehow fails "in the field",
> I think most people won't be able to recompile their own Linux
> kernel with debug messages let alone add their own debug messages.
>
> Anyway, I'll just make everything dev_dbg to avoid further discussion.
There's always the 'loglevel' command-line parameter, but yes, that
probably do not cover all cases.
> > > So in my humble opinion, version was the correct location, it
> > > is just a confusing name. (i.e. you can have many *versions*
> > > of an EIP197B, for instance ...)
> >
> > That would be an issue with the driver. We named the 'version' given the
> > knowledge we had of the h/w, it might not be specific enough. Or maybe
> > you can think of this as being a "family of engine versions". The idea
> > is the version is what the h/w is capable of, not how it's being
> > wired/accessed.
>
> Well ... I want to avoid the whole discussion about the naming of the
> variable (which can be trivially changed) and what the intention may
> have been, if you allow me.
>
> Fact is ... this variable is what receives .data / .driver_data from the
> OF or PCI match table. So it is a means of conveying a value that is
> specific to the table entry that was matched. No more, no less.
> In "your" device tree case you want to distinguish between
> Armada 39x, Armada 7K/8K and Armada 9K. In "my" PCI case I
> want to potentially distinguish multiple FPGA boards/images.
>
> It wouldn't make much sense to me to do the vendor/subvendor/
> device/subdevice decoding all over again in my probe routine.
> So what exactly is so very wrong with the way I'm doing this?
I think what is an issue for me here is the re-use of a variable
intended to only control the version of the engine. And the way this
engine is probed/accessed has nothing to do with this.
One solution, that I think would work for both of us, would be to still
keep this information in .data (as you did) but to organise it within a
struct so that the version information is split from the way the device
is accessed. Would that work for you?
('version' can probably be a value and not a bitfield then).
I'm sorry if the discussion about this point seems disproportionate
compared to technical aspect, but I would like to avoid possible
maintenance issues in the future with conditions looking like:
if (version == EIP197)
Which could easily be merged in a big patch but would break the
existing, given on what h/w the submitter tested the changes.
> > > > > @@ -1189,13 +1249,12 @@ static int safexcel_remove(struct platform_device *pdev)
> > > > > .compatible = "inside-secure,safexcel-eip197d",
> > > > > .data = (void *)EIP197D,
> > > > > },
> > > > > + /* For backward compatibiliry and intended for generic use */
> > > > > {
> > > > > - /* Deprecated. Kept for backward compatibility. */
> > > > > .compatible = "inside-secure,safexcel-eip97",
> > > > > .data = (void *)EIP97IES,
> > > > > },
> > > > > {
> > > > > - /* Deprecated. Kept for backward compatibility. */
> > > > > .compatible = "inside-secure,safexcel-eip197",
> > > > > .data = (void *)EIP197B,
> > > > > },
> > > >
> > > > I'm not sure about this. The compatible should describe what the
> > > > hardware is, and the driver can then decide if it has special things to
> > > > do or not. It is not used to configure the driver to be used with a
> > > > generic use or not.
> > > >
> > > > Do you have a practical reason to do this?
> > >
> > > I have to admit I don't fully understand how these compatible
> > > strings work. All I wanted to achieve is provide some generic
> > > device tree entry to point to this driver, to be used for
> > > devices other than Marvell. No need to convey b/d that way
> > > (or even eip97/197, for that matter) as that can all be probed.
> >
> > Compatibles are used in device trees, which intend to be a description
> > of the hardware (not the configuration of how the hardware should be
> > used). So we can't have a compatible being a restricted configuration
> > use of a given hardware. But I think here you're right, and there is
> > room for a more generic eip197 compatible: the b/d versions only have
> > few differences and are part of the same family, so we can have a very
> > specific compatible plus a "family" one. Something like:
> >
> > compatible = "inside-secure,safexcel-eip197d", "inside-secure,safexcel-eip197";
> >
> > This would need to be in a separated patch, and this should be
> > documented in:
> > Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
> >
> Ok, then I'll leave that part untouched for now.
> (I only changed the comments anyway ...)
Feel free to send a patch later on :) (Even if it's only about the
comment, it is important as well).
> > > > > +static struct pci_driver crypto_is_pci_driver = {
> > > > > + .name = "crypto-safexcel",
> > > > > + .id_table = crypto_is_pci_ids,
> > > > > + .probe = crypto_is_pci_probe,
> > > > > + .remove = crypto_is_pci_remove,
> > > > > +};
> > > >
> > > > More generally, you should protect all the PCI specific functions and
> > > > definitions between #ifdef.
> > > >
> > > I asked the mailing list and the answer was I should NOT use #ifdef,
> > > but instead use IS_ENABLED to *only* remove relevant function bodies.
> > > Which is exactly what I did (or tried to do, anyway).
> >
> > My bad, I realise there's a mistake in my comment. That should have
> > been: you should protect all the PCI specific functions and definitions
> > with #if IS_ENABLED(...). When part of a function should be excluded
> > you can use if(IS_ENABLED(...)), but if the entire function can be left
> > out, #if is the way to go.
> >
> Ok #if instead of if or #ifdef,that makes sense.
> So can I just put all the PCI stuff into one big #if then?
Right.
You may also want to check for for helpers only defined if CONFIG_OF
is selected, as the driver could be compiled for a kernel with only
CONFIG_PCI enabled.
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 05/20] hw/i386/pc: Add documentation to the e820_*() functions
From: Michael S. Tsirkin @ 2019-06-20 15:36 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: qemu-devel, Marcel Apfelbaum, Richard Henderson, Rob Bradford,
Eduardo Habkost, kvm, Marcelo Tosatti, Samuel Ortiz, Yang Zhong,
Paolo Bonzini
In-Reply-To: <20190613143446.23937-6-philmd@redhat.com>
On Thu, Jun 13, 2019 at 04:34:31PM +0200, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> include/hw/i386/pc.h | 37 +++++++++++++++++++++++++++++++++++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 7c07185dd5..fc66b61ff8 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -293,9 +293,42 @@ typedef enum {
> E820_UNUSABLE = 5
> } E820Type;
>
> -ssize_t e820_add_entry(uint64_t, uint64_t, uint32_t);
> +/**
> + * e820_add_entry: Add an #e820_entry to the @e820_table.
> + *
> + * Returns the number of entries of the e820_table on success,
> + * or a negative errno otherwise.
> + *
> + * @address: The base address of the structure which the BIOS is to fill in.
> + * @length: The length in bytes of the structure passed to the BIOS.
> + * @type: The #E820Type of the address range.
> + */
> +ssize_t e820_add_entry(uint64_t address, uint64_t length, E820Type type);
> +
> +/**
> + * e820_get_num_entries: The number of entries of the @e820_table.
> + *
> + * Returns the number of entries of the e820_table.
> + */
> size_t e820_get_num_entries(void);
> -bool e820_get_entry(unsigned int, uint32_t, uint64_t *, uint64_t *);
> +
> +/**
> + * e820_get_entry: Get the address/length of an #e820_entry.
> + *
> + * If the #e820_entry stored at @index is of #E820Type @type, fills @address
> + * and @length with the #e820_entry values and return @true.
> + * Return @false otherwise.
> + *
> + * @index: The index of the #e820_entry to get values.
> + * @type: The @E820Type of the address range expected.
> + * @address: Pointer to the base address of the #e820_entry structure to
> + * be filled.
> + * @length: Pointer to the length (in bytes) of the #e820_entry structure
> + * to be filled.
> + * @return: true if the entry was found, false otherwise.
I don't actually care whether it's @E820Type, #E820Type or just type,
we should be consistent. I also find this style of documentation
underwhelming. what is to be filled? length or the structure?
upper case after : also looks somewhat wrong.
Same applies to other comments too.
> + */
> +bool e820_get_entry(unsigned int index, E820Type type,
> + uint64_t *address, uint64_t *length);
>
> extern GlobalProperty pc_compat_4_0_1[];
> extern const size_t pc_compat_4_0_1_len;
> --
> 2.20.1
^ permalink raw reply
* OpenBMC Hackathon will be at OSFC Sept 2019
From: Nancy Yuen @ 2019-06-20 15:34 UTC (permalink / raw)
To: OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]
OpenBMC will hold a Hackathon as part of the Open Source Firmware Conference
<https://osfc.io/> (OSFC) in September. OpenBMC will have it's own track
there. Several other firmware projects will also represented.
Registration is required and there is a limit on the number of spots added
with this track. Please register <https://osfc.io/tickets> early.
There is an attendee scholarship for students or people who work on any of
the Open Source firmware projects on their own time, not part of their day
job.
*Location*
Presentations Sept 3-4 @ Google in Sunnyvale
Google Building MP1
1155 Borregas Ave
Sunnyvale, CA, 94089
USA
Hacking Sept 5-6 @ Facebook in
Facebook Building MPK60
150 Independence Dr
Menlo Park, CA, 94025
USA
*Presentations*
There is a deadline for submitting a presentation <https://osfc.io/speakers>
is *June 30th*. OpenBMC has its own track but will also include other BMC
related talks. Presenters receive complimentary admission. (When you see
paper below, they really mean presentation). The audience at the OpenBMC
track may include people from the other projects.
*Please mark talks for the OpenBMC track with OpenBMC in the title.*
Day 1&2 Submissions:
Submissions may be in abstract, outline, or slide deck form. Submissions
must be in English.
These presentations will take place @ Google. OSFC wants these to be set
in the schedule and announced ahead of time.
Day 3&4 Lightning Talk Submission:
These are meant for shorter "talks". Some lightning talks can be added
later. Short abstract submission only. Please mark your submission by
adding "lightning talk" to the title.
These days are meant for hacking and more ad-hoc discussions so the plan is
to leave room for those.
----------
Nancy
[-- Attachment #2: Type: text/html, Size: 2427 bytes --]
^ permalink raw reply
* Re: [PATCH] SUNRPC: Fix a credential refcount leak
From: Ido Schimmel @ 2019-06-20 15:35 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Anna Schumaker, linux-nfs
In-Reply-To: <20190620144740.4169-1-trond.myklebust@hammerspace.com>
On Thu, Jun 20, 2019 at 10:47:40AM -0400, Trond Myklebust wrote:
> All callers of __rpc_clone_client() pass in a value for args->cred,
> meaning that the credential gets assigned and referenced in
> the call to rpc_new_client().
>
> Reported-by: Ido Schimmel <idosch@idosch.org>
> Fixes: 79caa5fad47c ("SUNRPC: Cache cred of process creating the rpc_client")
> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: Ido Schimmel <idosch@mellanox.com>
Thanks a lot!
^ permalink raw reply
* Re: [PATCH] slub: Don't panic for memcg kmem cache creation failure
From: Michal Hocko @ 2019-06-20 15:35 UTC (permalink / raw)
To: Shakeel Butt
Cc: Johannes Weiner, Christoph Lameter, Andrew Morton, Roman Gushchin,
Pekka Enberg, David Rientjes, Joonsoo Kim, Cgroups, Linux MM,
LKML, Dave Hansen
In-Reply-To: <CALvZod4Fd5X91CzDLaVAvspQL-zoD7+9OGTiOro-hiMda=DqBA@mail.gmail.com>
On Thu 20-06-19 07:44:27, Shakeel Butt wrote:
> On Wed, Jun 19, 2019 at 10:50 PM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Wed 19-06-19 16:25:14, Shakeel Butt wrote:
> > > Currently for CONFIG_SLUB, if a memcg kmem cache creation is failed and
> > > the corresponding root kmem cache has SLAB_PANIC flag, the kernel will
> > > be crashed. This is unnecessary as the kernel can handle the creation
> > > failures of memcg kmem caches.
> >
> > AFAICS it will handle those by simply not accounting those objects
> > right?
> >
>
> The memcg kmem cache creation is async. The allocation has already
> been decided not to be accounted on creation trigger. If memcg kmem
> cache creation is failed, it will fail silently and the next
> allocation will trigger the creation process again.
Ohh, right I forgot that it will get retried. This would be useful to
mention in the changelog as it is not straightforward from reading just
the particular function.
> > > Additionally CONFIG_SLAB does not
> > > implement this behavior. So, to keep the behavior consistent between
> > > SLAB and SLUB, removing the panic for memcg kmem cache creation
> > > failures. The root kmem cache creation failure for SLAB_PANIC correctly
> > > panics for both SLAB and SLUB.
> >
> > I do agree that panicing is really dubious especially because it opens
> > doors to shut the system down from a restricted environment. So the
> > patch makes sesne to me.
> >
> > I am wondering whether SLAB_PANIC makes sense in general though. Why is
> > it any different from any other essential early allocations? We tend to
> > not care about allocation failures for those on bases that the system
> > must be in a broken state to fail that early already. Do you think it is
> > time to remove SLAB_PANIC altogether?
> >
>
> That would need some investigation into the history of SLAB_PANIC. I
> will look into it.
Well, I strongly suspect this is a relict from the past. I have hard
time to believe that the system would get to a usable state if many of
those caches would fail to allocate. And as Dave said in his reply it is
quite silly to give this weapon to a random driver hands. Everybody just
thinks his toy is the most important one...
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 3/4] update-alternatives.bbclass: run update-alternatives firstly in postinst script
From: Richard Purdie @ 2019-06-20 15:33 UTC (permalink / raw)
To: Robert Yang, openembedded-core
In-Reply-To: <d02500d78c61f9cdee7a5f4bc99148379054cfcd.1561018476.git.liezhi.yang@windriver.com>
On Thu, 2019-06-20 at 16:15 +0800, Robert Yang wrote:
> Recipes like postfix run command newaliases in postinst, but
> newaliases is
> installed newaliases.postfix, and need run update-alternatives to
> update it to
> newaliases, so we would get the error when install postinst on
> target.
>
> Fixed:
> $ opkg install postfix
> Configuring postfix.
> ///var/lib/opkg/info/postfix.postinst: line 4: newaliases: command
> not found
>
> Run update-alternatives firstly will fix the problem.
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
> meta/classes/update-alternatives.bbclass | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
This seemed to result in:
https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/724
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 1/1] xfsprogs: Fix uninitialized cfg->lsunit
From: Darrick J. Wong @ 2019-06-20 15:32 UTC (permalink / raw)
To: Allison Collins; +Cc: linux-xfs
In-Reply-To: <20190619182857.9959-1-allison.henderson@oracle.com>
On Wed, Jun 19, 2019 at 11:28:57AM -0700, Allison Collins wrote:
> While investigating another mkfs bug, noticed that cfg->lsunit is sometimes
> left uninitialized when it should not. This is because calc_stripe_factors
> in some cases needs cfg->loginternal to be set first. This is done in
> validate_logdev. So move calc_stripe_factors below validate_logdev while
> parsing configs.
<grumble> The cfg in main() is not (in a manner easily detectable by
toolz) uninitialized, it's zero-initialized by default and we haven't
set cfg->loginternal correctly yet...
...what we really need here is enum { FALSE, TRUE, FILENOTFOUND } to
detect that we're using incorrect garbage data. :P
(Really, someone should take a closer look at whether or not there are
other places where we do things like this...)
Anyway, this does solve a problem, so
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
--D
>
> Signed-off-by: Allison Collins <allison.henderson@oracle.com>
> ---
> mkfs/xfs_mkfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> index ddb25ec..f4a5e4b 100644
> --- a/mkfs/xfs_mkfs.c
> +++ b/mkfs/xfs_mkfs.c
> @@ -3995,7 +3995,6 @@ main(
> cfg.rtblocks = calc_dev_size(cli.rtsize, &cfg, &ropts, R_SIZE, "rt");
>
> validate_rtextsize(&cfg, &cli, &ft);
> - calc_stripe_factors(&cfg, &cli, &ft);
>
> /*
> * Open and validate the device configurations
> @@ -4005,6 +4004,7 @@ main(
> validate_datadev(&cfg, &cli);
> validate_logdev(&cfg, &cli, &logfile);
> validate_rtdev(&cfg, &cli, &rtfile);
> + calc_stripe_factors(&cfg, &cli, &ft);
>
> /*
> * At this point when know exactly what size all the devices are,
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support
From: Christian Lamparter @ 2019-06-20 15:32 UTC (permalink / raw)
To: Sricharan R
Cc: devicetree, Stephen Boyd, linux-arm-msm, Linus Walleij, agross,
linux-kernel, Павел,
open list:GPIO SUBSYSTEM, Rob Herring, linux-soc, linux-clk,
linux-arm Mailing List
In-Reply-To: <96fd8992-e333-6b3b-15c0-2845984120aa@codeaurora.org>
Hello Sricharan,
On Wednesday, June 19, 2019 4:42:11 PM CEST Sricharan R wrote:
> On 6/15/2019 2:11 AM, Christian Lamparter wrote:
> > On Wednesday, June 12, 2019 11:48:48 AM CEST Sricharan R wrote:
> >> Hi Christian,
> >>
> >> On 6/10/2019 5:45 PM, Christian Lamparter wrote:
> >>> On Monday, June 10, 2019 12:09:56 PM CEST Sricharan R wrote:
> >>>> Hi Christian,
> >>>>
> >>>> On 6/6/2019 2:11 AM, Christian Lamparter wrote:
> >>>>> On Wed, Jun 5, 2019 at 7:16 PM Sricharan R <sricharan@codeaurora.org> wrote:
> >>>>>>
> >>>>>> Add initial device tree support for the Qualcomm IPQ6018 SoC and
> >>>>>> CP01 evaluation board.
> >>>>>>
> >>>>>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> >>>>>> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> >>>>>> --- /dev/null
> >>>>>> +++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> >>>>>>
> >>>>>> + clocks {
> >>>>>> + sleep_clk: sleep_clk {
> >>>>>> + compatible = "fixed-clock";
> >>>>>> + clock-frequency = <32000>;
> >>>>>> + #clock-cells = <0>;
> >>>>>> + };
> >>>>>> +
> >>>>> Recently-ish, we ran into an issue with the clock-frequency of the sleep_clk
> >>>>> on older IPQ40XX (and IPQ806x) on the OpenWrt Github and ML.
> >>>>> From what I know, the external "32KHz" crystals have 32768 Hz, but the QSDK
> >>>>> declares them at 32000 Hz. Since you probably have access to the BOM and
> >>>>> datasheets. Can you please confirm what's the real clock frequency for
> >>>>> the IPQ6018.
> >>>>> (And maybe also for the sleep_clk of the IPQ4018 as well?).
> >>>>>
> >>>>
> >>>> What exactly is the issue that you faced ?
> >>>> Looking in to the docs, it is <32000> only on ipq6018 and ipq40xx as well.
> >>>
> >>> We need just a confirmation.
> >>>
> >>> Then again, Currently the qcom-ipq4019.dtsi is using 32768 Hz.
> >>>
> >>> | sleep_clk: sleep_clk {
> >>> | compatible = "fixed-clock";
> >>> | clock-frequency = <32768>;
> >>> | #clock-cells = <0>;
> >>> | };
> >>>
> >>> <https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom-ipq4019.dtsi#L144>
> >>>
> >>> Which makes sense, because all previous Qualcomm Atheros MIPS and the
> >>> future IPQ8072 SoCs have been either using or deriving a 32768 Hz clock.
> >>>
> >>> For example: The AR9344 derives the clock from the 25MHz/40MHz external
> >>> oscillator. This is explained in "8.16.9 Derived RTC Clock (DERIVED_RTC_CLK)".
> >>> Which mentions that the "32KHz" clock interval is 30.5 usec / 30.48 usec
> >>> depending whenever the external reference crystal has 40MHz or 25MHz.
> >>> (1/30.5usec = 32.7868852 kilohertz!). The QCA9558 datasheet says the same
> >>> in "10.19.11 Derived RTC Clock".
> >>>
> >>> For IPQ8072: I point to the post by Sven Eckelmann on the OpenWrt ML:
> >>> <http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017131.html>
> >>> "I was only able to verify for IPQ8072 that it had a 32.768 KHz
> >>> sleep clock."
> >>>
> >>> So this is pretty much "why there is an issue", it's confusing.
> >>> Is possible can you please look if there are (fixed) divisors values
> >>> listed in the documentation or the registers and bits that the values
> >>> are stored in? Because then we could just calculate it.
> >>>
> >>
> >> Really sorry for the confusion. So looking little more, SLEEP_CLK is derived
> >> from an external 38.4MHZ crystal, it is 32.768 KHZ.
> > That's really valuable information to have. Thank you!
> >
> >> Somehow the clk freq plan etc seems to mention them only as .032 MHZ and misses
> >> out. That means i will correct the patch for 32768 and probably the
> >> ipq8074.dtsi as well
> >
> > Ok, there's one more issue that Paul found (at least with the IPQ4019),
> > https://patchwork.ozlabs.org/patch/1099482
> >
> > it seems that the "sleep_clk" node in the qcom-ipq4019.dtsi is not used by
> > the gcc-ipq4019.c clk driver. this causes both wifi rtc_clks and the usb sleep
> > clks to dangle in the /sys/kernel/debug/clk/clk_summary (from a RT-AC58U)
> >
> > clock enable_cnt prepare_cnt rate accuracy phase
> > ----------------------------------------------------------------------------------------
> > xo 9 9 48000000 0 0
> > [...]
> > sleep_clk 1 1 32768 0 0
> > gcc_wcss5g_rtc_clk 1 1 0 0 0
> > gcc_wcss2g_rtc_clk 1 1 0 0 0
> > gcc_usb3_sleep_clk 1 1 0 0 0
> > gcc_usb2_sleep_clk 1 1 0 0 0
> >
> > with his patch the /sys/kernel/debug/clk/clk_summary looks "better"
> >
> > (something like this:)
> >
> > clock enable_cnt prepare_cnt rate accuracy phase
> > ----------------------------------------------------------------------------------------
> > xo 9 9 48000000 0 0
> > [...]
> > gcc_sleep_clk_src 5 5 32000 0 0
> > gcc_wcss5g_rtc_clk 1 1 32000 0 0
> > gcc_wcss2g_rtc_clk 1 1 32000 0 0
> > gcc_usb3_sleep_clk 1 1 32000 0 0
> > gcc_usb2_sleep_clk 1 1 32000 0 0
> >
> > but judging from your comment "SLEEP_CLK is derived from an
> > external 38.4MHZ crystal" the gcc_sleep_clk_src / sleep_clk
> > should have xo as the parent. so the ideal output should be:
> >
> > clock enable_cnt prepare_cnt rate accuracy phase
> > ----------------------------------------------------------------------------------------
> > xo 10 10 48000000 0 0
> > [...]
> > gcc_sleep_clk 5 5 32768 0 0
> > gcc_wcss5g_rtc_clk 1 1 32768 0 0
> > gcc_wcss2g_rtc_clk 1 1 32768 0 0
> > gcc_usb3_sleep_clk 1 1 32768 0 0
> > gcc_usb2_sleep_clk 1 1 32768 0 0
> >
> > or am I missing/skipping over something important?
> >
>
> Sorry for the delayed response. So what i said above (32768 clk) looks
> like true only for ipq8074. For ipq4019, looks like 32000.
>
> That means, there is still some thing unclear. I am checking for precise
> information from HW team for ipq4019/8074/6018. Please hang on, will
> update you asap.
Thank you for looking this up! I'll definitely stick around for the final
verdict.
Also, I think the "xo" clk of your IPQ6018 dts should get the
"always-on;" property (any maybe sleep_clk as well?).
Paul discovered that the QSDK had this extra commit
<https://lore.kernel.org/patchwork/patch/1089385/>
(Maybe the changeid can help you look it up internally)
For IPQ4019, this enables the high resolution with a 1ns resolution
instead of 10ms.
(echo q > /proc/sysrq-trigger can be used to check this just look for
the "resolution" value before and after.)
Cheers,
Christian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support
From: Christian Lamparter @ 2019-06-20 15:32 UTC (permalink / raw)
To: Sricharan R
Cc: Rob Herring, Stephen Boyd, Linus Walleij, agross, devicetree,
linux-kernel, linux-clk, open list:GPIO SUBSYSTEM, linux-arm-msm,
linux-soc, linux-arm Mailing List,
Павел
In-Reply-To: <96fd8992-e333-6b3b-15c0-2845984120aa@codeaurora.org>
Hello Sricharan,
On Wednesday, June 19, 2019 4:42:11 PM CEST Sricharan R wrote:
> On 6/15/2019 2:11 AM, Christian Lamparter wrote:
> > On Wednesday, June 12, 2019 11:48:48 AM CEST Sricharan R wrote:
> >> Hi Christian,
> >>
> >> On 6/10/2019 5:45 PM, Christian Lamparter wrote:
> >>> On Monday, June 10, 2019 12:09:56 PM CEST Sricharan R wrote:
> >>>> Hi Christian,
> >>>>
> >>>> On 6/6/2019 2:11 AM, Christian Lamparter wrote:
> >>>>> On Wed, Jun 5, 2019 at 7:16 PM Sricharan R <sricharan@codeaurora.org> wrote:
> >>>>>>
> >>>>>> Add initial device tree support for the Qualcomm IPQ6018 SoC and
> >>>>>> CP01 evaluation board.
> >>>>>>
> >>>>>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> >>>>>> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> >>>>>> --- /dev/null
> >>>>>> +++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> >>>>>>
> >>>>>> + clocks {
> >>>>>> + sleep_clk: sleep_clk {
> >>>>>> + compatible = "fixed-clock";
> >>>>>> + clock-frequency = <32000>;
> >>>>>> + #clock-cells = <0>;
> >>>>>> + };
> >>>>>> +
> >>>>> Recently-ish, we ran into an issue with the clock-frequency of the sleep_clk
> >>>>> on older IPQ40XX (and IPQ806x) on the OpenWrt Github and ML.
> >>>>> From what I know, the external "32KHz" crystals have 32768 Hz, but the QSDK
> >>>>> declares them at 32000 Hz. Since you probably have access to the BOM and
> >>>>> datasheets. Can you please confirm what's the real clock frequency for
> >>>>> the IPQ6018.
> >>>>> (And maybe also for the sleep_clk of the IPQ4018 as well?).
> >>>>>
> >>>>
> >>>> What exactly is the issue that you faced ?
> >>>> Looking in to the docs, it is <32000> only on ipq6018 and ipq40xx as well.
> >>>
> >>> We need just a confirmation.
> >>>
> >>> Then again, Currently the qcom-ipq4019.dtsi is using 32768 Hz.
> >>>
> >>> | sleep_clk: sleep_clk {
> >>> | compatible = "fixed-clock";
> >>> | clock-frequency = <32768>;
> >>> | #clock-cells = <0>;
> >>> | };
> >>>
> >>> <https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom-ipq4019.dtsi#L144>
> >>>
> >>> Which makes sense, because all previous Qualcomm Atheros MIPS and the
> >>> future IPQ8072 SoCs have been either using or deriving a 32768 Hz clock.
> >>>
> >>> For example: The AR9344 derives the clock from the 25MHz/40MHz external
> >>> oscillator. This is explained in "8.16.9 Derived RTC Clock (DERIVED_RTC_CLK)".
> >>> Which mentions that the "32KHz" clock interval is 30.5 usec / 30.48 usec
> >>> depending whenever the external reference crystal has 40MHz or 25MHz.
> >>> (1/30.5usec = 32.7868852 kilohertz!). The QCA9558 datasheet says the same
> >>> in "10.19.11 Derived RTC Clock".
> >>>
> >>> For IPQ8072: I point to the post by Sven Eckelmann on the OpenWrt ML:
> >>> <http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017131.html>
> >>> "I was only able to verify for IPQ8072 that it had a 32.768 KHz
> >>> sleep clock."
> >>>
> >>> So this is pretty much "why there is an issue", it's confusing.
> >>> Is possible can you please look if there are (fixed) divisors values
> >>> listed in the documentation or the registers and bits that the values
> >>> are stored in? Because then we could just calculate it.
> >>>
> >>
> >> Really sorry for the confusion. So looking little more, SLEEP_CLK is derived
> >> from an external 38.4MHZ crystal, it is 32.768 KHZ.
> > That's really valuable information to have. Thank you!
> >
> >> Somehow the clk freq plan etc seems to mention them only as .032 MHZ and misses
> >> out. That means i will correct the patch for 32768 and probably the
> >> ipq8074.dtsi as well
> >
> > Ok, there's one more issue that Paul found (at least with the IPQ4019),
> > https://patchwork.ozlabs.org/patch/1099482
> >
> > it seems that the "sleep_clk" node in the qcom-ipq4019.dtsi is not used by
> > the gcc-ipq4019.c clk driver. this causes both wifi rtc_clks and the usb sleep
> > clks to dangle in the /sys/kernel/debug/clk/clk_summary (from a RT-AC58U)
> >
> > clock enable_cnt prepare_cnt rate accuracy phase
> > ----------------------------------------------------------------------------------------
> > xo 9 9 48000000 0 0
> > [...]
> > sleep_clk 1 1 32768 0 0
> > gcc_wcss5g_rtc_clk 1 1 0 0 0
> > gcc_wcss2g_rtc_clk 1 1 0 0 0
> > gcc_usb3_sleep_clk 1 1 0 0 0
> > gcc_usb2_sleep_clk 1 1 0 0 0
> >
> > with his patch the /sys/kernel/debug/clk/clk_summary looks "better"
> >
> > (something like this:)
> >
> > clock enable_cnt prepare_cnt rate accuracy phase
> > ----------------------------------------------------------------------------------------
> > xo 9 9 48000000 0 0
> > [...]
> > gcc_sleep_clk_src 5 5 32000 0 0
> > gcc_wcss5g_rtc_clk 1 1 32000 0 0
> > gcc_wcss2g_rtc_clk 1 1 32000 0 0
> > gcc_usb3_sleep_clk 1 1 32000 0 0
> > gcc_usb2_sleep_clk 1 1 32000 0 0
> >
> > but judging from your comment "SLEEP_CLK is derived from an
> > external 38.4MHZ crystal" the gcc_sleep_clk_src / sleep_clk
> > should have xo as the parent. so the ideal output should be:
> >
> > clock enable_cnt prepare_cnt rate accuracy phase
> > ----------------------------------------------------------------------------------------
> > xo 10 10 48000000 0 0
> > [...]
> > gcc_sleep_clk 5 5 32768 0 0
> > gcc_wcss5g_rtc_clk 1 1 32768 0 0
> > gcc_wcss2g_rtc_clk 1 1 32768 0 0
> > gcc_usb3_sleep_clk 1 1 32768 0 0
> > gcc_usb2_sleep_clk 1 1 32768 0 0
> >
> > or am I missing/skipping over something important?
> >
>
> Sorry for the delayed response. So what i said above (32768 clk) looks
> like true only for ipq8074. For ipq4019, looks like 32000.
>
> That means, there is still some thing unclear. I am checking for precise
> information from HW team for ipq4019/8074/6018. Please hang on, will
> update you asap.
Thank you for looking this up! I'll definitely stick around for the final
verdict.
Also, I think the "xo" clk of your IPQ6018 dts should get the
"always-on;" property (any maybe sleep_clk as well?).
Paul discovered that the QSDK had this extra commit
<https://lore.kernel.org/patchwork/patch/1089385/>
(Maybe the changeid can help you look it up internally)
For IPQ4019, this enables the high resolution with a 1ns resolution
instead of 10ms.
(echo q > /proc/sysrq-trigger can be used to check this just look for
the "resolution" value before and after.)
Cheers,
Christian
^ 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.