lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191108114244.357c594f@canb.auug.org.au>
Date:   Fri, 8 Nov 2019 11:42:44 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Dave Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Intel Graphics <intel-gfx@...ts.freedesktop.org>,
        DRI <dri-devel@...ts.freedesktop.org>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>
Subject: Re: linux-next: manual merge of the drm tree with the
 drm-intel-fixes tree

Hi all,

This is now a conflict between the drm tree and Linus' tree.

On Thu, 31 Oct 2019 11:33:15 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
> 
>   drivers/gpu/drm/i915/i915_drv.h
> 
> between commit:
> 
>   59cd826fb5e7 ("drm/i915: Fix PCH reference clock for FDI on HSW/BDW")
> 
> from the drm-intel-fixes tree and commit:
> 
>   7d423af9bfb1 ("drm/i915: Implement a better i945gm vblank irq vs. C-states workaround")
> 
> from the drm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/i915_drv.h
> index 953e1d12c23c,8882c0908c3b..000000000000
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@@ -1704,34 -1339,17 +1339,19 @@@ struct drm_i915_private 
>   	struct {
>   		struct notifier_block pm_notifier;
>   
> - 		/**
> - 		 * We leave the user IRQ off as much as possible,
> - 		 * but this means that requests will finish and never
> - 		 * be retired once the system goes idle. Set a timer to
> - 		 * fire periodically while the ring is running. When it
> - 		 * fires, go retire requests.
> - 		 */
> - 		struct delayed_work retire_work;
> - 
> - 		/**
> - 		 * When we detect an idle GPU, we want to turn on
> - 		 * powersaving features. So once we see that there
> - 		 * are no more requests outstanding and no more
> - 		 * arrive within a small period of time, we fire
> - 		 * off the idle_work.
> - 		 */
> - 		struct work_struct idle_work;
> + 		struct i915_gem_contexts {
> + 			spinlock_t lock; /* locks list */
> + 			struct list_head list;
> + 
> + 			struct llist_head free_list;
> + 			struct work_struct free_work;
> + 		} contexts;
>   	} gem;
>   
>  +	u8 pch_ssc_use;
>  +
> - 	/* For i945gm vblank irq vs. C3 workaround */
> - 	struct {
> - 		struct work_struct work;
> - 		struct pm_qos_request pm_qos;
> - 		u8 c3_disable_latency;
> - 		u8 enabled;
> - 	} i945gm_vblank;
> + 	/* For i915gm/i945gm vblank irq workaround */
> + 	u8 vblank_enabled;
>   
>   	/* perform PHY state sanity checks? */
>   	bool chv_phy_assert[2];

-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ