c | 8 +--
> drivers/video/fbdev/vga16fb.c | 9 +--
> include/linux/console.h | 7 ++
> 42 files changed, 183 insertions(+), 252 deletions(-)
> delete mode 100644 arch/hexagon/kernel/screen_info.c
>
> --
> 2.39.2
>
> Cc: &qu
and parisc use pgprot_uncached here, but as
> they don't define a custom pgprot_writecombine, this ends up being
> the same, and they can use the above definition as well.
>
> mips defines pgprot_writecombine but uses pgprot_noncached
> in fb_pgprotect(), which is probably a mistake and shou
there are still 2 qestions to answer:
> > >
> > > 1. Name of the helper, __xchg follows kernel conventions,
> > > but for me Rust names are also OK.
> > I like replace(), or, shockingly, exchange().
> >
> > But... Can we simply make swap() return the previous value?
> >
> > previous_min_rate = swap(>qos.min_rate, min_rate);
>
> As Alexander already pointed out, swap requires 'references' to two
> variables,
> in contrast to xchg which requires reference to variable and value.
> So we cannot use swap for cases:
> old_value = __xchg(, new_value);
>
> Regards
> Andrzej
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
to be a legacy leftover. Let's just remove
> it.
>
> Cc: Inki Dae
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Krzysztof Kozlowski
> Signed-off-by: David Hildenbrand
Reviewed-by: Daniel Vetter
Plus ack for merging thr
issue has been resolved, FOLL_WRITE could
> again be set depending on the DMA direction.
>
> Cc: Hans Verkuil
> Cc: Marek Szyprowski
> Cc: Tomasz Figa
> Cc: Marek Szyprowski
> Cc: Mauro Carvalho Chehab
> Signed-off-by: David Hildenbrand
Also code I looked at while
ly, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required
> for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop
> using FOLL_FORCE, which is really only for ptrace access.
>
> Cc: Daniel Vetter
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
&
for ptrace access.
>
> Cc: Mauro Carvalho Chehab
> Signed-off-by: David Hildenbrand
I looked at this a while ago when going through some of the follow_pfn
stuff, so
Reviewed-by: Daniel Vetter
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 14 +-
> 1 file chang
d into some enterprise distros, and there were
> not any such complaints. So most probably, we're fine.
>
> Signed-off-by: David Hildenbrand
I don't think my ack is any good for the implementation, but for the
driver side semantics this sounds like what we want :-)
Acked-by: Daniel Vetter
On Thu, Aug 11, 2022 at 08:27:42PM +0200, Thomas Zimmermann wrote:
>
>
> Am 11.08.22 um 20:26 schrieb Thomas Zimmermann:
> > Hi Daniel
> >
> > Am 11.08.22 um 19:23 schrieb Daniel Vetter:
> > > On Wed, 27 Jul 2022 at 09:53, Thomas Zimmermann
> > > w
alas that's a pile of work and
not much payoff.
I'm trying to volunteer Same to add a legacy_bpp tag to the above
helper and appropriately limit it, I think limiting to formats with
depth!=0 is probably the right thing. And then we should probably
remove a pile of the cargo-culted depth!=0 entrie
n to really make
sure we got all the bug reports, since often these older machines only
update onto LTS releases.
And it needs to be a WARN_ON + bail out since BUG_ON is as bad as just
oopsing.
-Daniel
>
> Regardless of what you chose to do, the patch looks good to me.
>
> Reviewed-by: Javier Martinez Canillas
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, May 04, 2021 at 12:53:27PM -0300, Jason Gunthorpe wrote:
> On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote:
>
> > Just my 2cents from drm (where we deprecate old gunk uapi quite often):
> > Imo it's best to keep the uapi headers as-is, but exchange the
ions or
whatever they are in this case) are defacto reserved, because there are
binaries (qemu in this) that have code acting on them out there.
The only exception where we completely nuke the structs and #defines is
when uapi has been only used by testcases. Which we know, since we defacto
limit our stable uapi guarantee to the canonical open userspace
drivers only (for at least the driver-specific stuff, the cross-driver
interfaces are hopeless).
Anyway feel free to ignore since this might be different than drivers/gpu.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
is harmless if the module is already loaded (and not
> other caller has this find_module check either).
>
> Signed-off-by: Christoph Hellwig
Hm I thought I've acked this one already somewhere for merging through
your tree.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_
On Thu, Jan 21, 2021 at 9:28 AM Christoph Hellwig wrote:
>
> On Thu, Jan 21, 2021 at 09:25:40AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 21, 2021 at 8:55 AM Christoph Hellwig wrote:
> > >
> > > drm_fb_helper_modinit has a lot of boilerplate for what is not v
console symbols. At least
> +* attempt to load fbcon to avoid leaving the system without a usable
> +* console.
> +*/
> + if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) &&
> + IS_MODULE(CONFIG_FRAMEBUFFER_CONSOLE) &&
> + !IS_ENABLED(CONFIG_EXPERT) &&
> + !module_loaded("fbcon"))
> + request_module_nowait("fbcon");
> +
> + return drm_dp_aux_dev_init();
> }
>
> static void __exit drm_kms_helper_exit(void)
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Oct 09, 2020 at 12:49:44PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> These kmap() calls in the gpu stack are localized to a single thread.
> To avoid the over head of global PKRS updates use the new kmap_thread()
> call.
>
> Cc: David Airlie
>
On Sun, Sep 20, 2020 at 08:23:26AM +0200, Thomas Gleixner wrote:
> On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote:
> > On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote:
> >> I think it should be the case, but I want to double check: Will
> >> copy_*_user be allo
On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote:
>
> On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner wrote:
> >
> > First of all, sorry for the horribly big Cc list!
> >
> > Following up to the discussion in:
> >
> > https://lore.kernel.or
arch/xtensa/include/asm/highmem.h |9 +
> arch/xtensa/mm/highmem.c | 44 ---
> b/arch/x86/Kconfig|3
> include/linux/highmem.h | 141 +++-
> include/linux/io-mapping.h|2
> include/l
n whether you will pick it up only confuses people and increases
the risk that patches get lost.
So either pick up right away, or state clearly that you will pick it up
later, or that you expect someone else to merge this.
Thanks, Daniel
>
> > Writeback Layer (wb_layer)
> > --
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 14, 2020 at 12:10:05PM +0200, Daniel Vetter wrote:
> This and next patch merged to drm-misc-next, thanks.
Oops strike this, I just noticed that Jon said he's picked it all up.
Oh well, the confusion, I managed to stop the script before it published
anything at least :-)
-Dan
ned-off-by: Ira Weiny
I'm assuming this lands through some other tree or a topic branch or whatever.
Acked-by: Daniel Vetter
Cheers, Daniel
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c| 56 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 16
> in
On Fri, Apr 10, 2020 at 12:57 AM Benjamin Herrenschmidt
wrote:
>
> On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote:
> > Now if these boxes didn't ever have agp then I think we can get away
> > with deleting this, since we've already deleted the legacy radeon
> > d
On Thu, Apr 9, 2020 at 4:19 PM Alex Deucher wrote:
>
> On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter wrote:
> >
> > On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
> > wrote:
> > >
> > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
wrote:
>
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > If this code was broken for non-coherent caches a crude powerpc hack
>
return -ENOMEM;
> }
>
> - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> if (!entry->virtual) {
> kfree(entry->busaddr);
> kfree(entry->pagelist);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+-
> drivers/gpu/drm/drm_ioctl.c | 2 +-
These two look very correct. The patch that moved edid.rst seems to have
not updated a lot of references :-/
Acked-by: Daniel Vetter
> drivers/hwtracing/coresight/Kconfig | 2 +-
> fs/fat/Kconfi
On Wed, Nov 13, 2019 at 11:12:10AM +0100, Jan Kara wrote:
> On Wed 13-11-19 01:02:02, John Hubbard wrote:
> > On 11/13/19 12:22 AM, Daniel Vetter wrote:
> > ...
> > > > > Why are we doing this? I think things got confused here someplace, as
>
get_user_pages(), and that's the IB ODP code.
>
> >
> > I feel like if put_user_pages() is not the correct way to undo
> > get_user_pages() then it needs to be deleted.
> >
>
> Yes, you're right. I'll fix the put_user_page comments() as described.
>
>
> thanks,
>
> John Hubbard
> NVIDIA
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon, Nov 04, 2019 at 11:20:38AM -0800, John Hubbard wrote:
> On 11/4/19 10:10 AM, Daniel Vetter wrote:
> > On Thu, Oct 31, 2019 at 04:36:28PM -0700, Ira Weiny wrote:
> >> On Wed, Oct 30, 2019 at 03:49:20PM -0700, John Hubbard wrote:
> >>> Convert drm/via to u
cking of pinned pages, and therefore for any code that calls
> > put_user_page().
> >
>
> Reviewed-by: Ira Weiny
No one's touching the via driver anymore, so feel free to merge this
through whatever tree suits best (aka I'll drop this on the floor and
forget about it now).
Acke
patch
here.
I trust you way more on the _PAGE_ flags than me, but this looks
reasonable.
Acked-by: Daniel Vetter
> ---
> drivers/video/fbdev/chipsfb.c| 3 +--
> drivers/video/fbdev/controlfb.c | 5 +
> drivers/video/fbdev/platinumfb.c | 5 +
> drivers/video/fbdev/valk
ed all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Daniel Vetter
At least for the drm and dma-buf bits.
-Daniel
> ---
> drivers/android/binder.c
t; ;-)
+1
But I'm biased, I'm part of the party that is responsible for the new
shiny documentation system ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_svm_d
> > * for example, an "address" value of 0x12345f000 will
> > * flush from 0x12344 to 0x12347 (256KiB). */
> > unsigned long last = address + ((unsigned long)(pages -
> > 1) << VTD_PAGE_SHIFT);
> > - unsigned long mask = __rounddown_pow_of_two(address ^
> > last);;
> > + unsigned long mask = __rounddown_pow_of_two(address ^
> > last);
> > desc.high = QI_DEV_EIOTLB_ADDR((address & ~mask) |
> > (mask - 1)) | QI_DEV_EIOTLB_SIZE;
> > } else {
> > diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> > index b2eae33..f978edd 100644
> > --- a/drivers/md/raid1.c
> > +++ b/drivers/md/raid1.c
> > @@ -1108,7 +1108,7 @@ static void alloc_behind_master_bio(struct r1bio
> > *r1_bio,
> > bio_copy_data(behind_bio, bio);
> > skip_copy:
> > - r1_bio->behind_master_bio = behind_bio;;
> > + r1_bio->behind_master_bio = behind_bio;
> > set_bit(R1BIO_BehindIO, _bio->state);
> > return;
> > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> > index 53f7275..cfb42f5 100644
> > --- a/drivers/soc/imx/gpc.c
> > +++ b/drivers/soc/imx/gpc.c
> > @@ -348,7 +348,7 @@ static int imx_gpc_old_dt_init(struct device *dev,
> > struct regmap *regmap,
> > if (i == 1) {
> > domain->supply = devm_regulator_get(dev, "pu");
> > if (IS_ERR(domain->supply))
> > - return PTR_ERR(domain->supply);;
> > + return PTR_ERR(domain->supply);
> > ret = imx_pgc_get_clocks(dev, domain);
> > if (ret)
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
I've now read over patch 1 to my
> satisfaction, so it too is:
>
> Reviewed-by: Daniel Axtens <d...@axtens.net>
Both applied for 4.15, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; > + if (vgadev->bridge_has_one_vga)
> > + vgaarb_info(dev, "bridge control possible\n");
> > + else
> > + vgaarb_info(dev, "no bridge control possible\n");
> > + }
>
> Initially I wondered if this info printk could be moved into
> vga_arbiter_check_bridge_sharing(), but it's been separated out since
> 3448a19da479b ("vgaarb: use bridges to control VGA routing where
> possible."), and upon closer examination, it seems you can't be sure a
> device doesn't share a bridge until the end of the process, so this is
> indeed correct.
>
> Everything else also looks good to me.
>
> Reviewed-by: Daniel Axtens <d...@axtens.net>
R-b for both patches? And ok with everyone if I pull this into drm-misc
for 4.15 (deadline is end of this week for feature-y stuff)?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
adds relevant documentation.
>>
>> The practical impact of this is improved X autoconfiguration on some
>> arm64 systems.
>>
>> Changes in v3:
>>
>> - Add documentation - thanks Daniel Vetter for pointing it out.
>>
>> - Clarify explanations. Thanks
E SOFTWARE OR THE USE OR OTHER
> + * DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef LINUX_VGA_DEFAULT_H
> +#define LINUX_VGA_DEFAULT_H
> +
> +struct pci_dev;
> +
> +#ifdef CONFIG_VGA_DEFAULT
> +extern struct pci_dev *vga_default_device(void);
> +extern voi
_
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nux/genwqe
> linux/genwqe/.install
> linux/genwqe/genwqe_card.h
> linux/genwqe/..install.cmd
> linux/seg6.h
> linux/cifs
> linux/cifs/.install
> linux/cifs/cifs_mount.h
> linux/cifs/..install.cmd
> linux/auto_dev-ioctl.h
>
> Thanks to Julien Floret <julien.flo..
we do the
>> request_firmware. Everything else we handle already in the kernel.
>
> OK so lets just get this userspace event done, and we're set.
Ah great. As long as that special wait-for-rootfs-pls firmware request
is still allowed, i915 folks will be happy. We will call it from
prob
On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote:
> On Wed, Aug 24, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
>> On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez <mcg...@kernel.org>
>> wrote:
>> > Thou shalt not make f
t; able to remove the usermode helper.
>
> [0]
> https://lkml.kernel.org/r/1440811107-861-1-git-send-email-mcg...@do-not-panic.com
>
> Cc: Alessandro Rubini <rub...@gnudd.com>
> Cc: Kevin Cernekee <cerne...@gmail.com>
> Cc: Daniel Vetter <daniel.vet...@ffwll.
uld be squashed together when
> applying.
For all the drm driver patches:
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Should I pull these in through drm-misc, or do you prefer to merge them
through a special topic branch (with everything else) instead on your own?
-Daniel
>
>
> u32 user_ptr_to_u32(void __user *p)
> u64 user_ptr_to_u64(void __user *p)
>
> Maybe there's something about 32 bit userspace on
> 64 OS that should be done too.
Tbh I really don't think we should add 32bit variants and encourage the
mispractice of having 32bit u
for
the same symbol.
I think if we get the BACKLIGHT_CLASS_DEVICE out of the picture with that
ACPI_VIDEO should be fixable with some
select ACPI_VIDEO if ACPI
or so. Currently that doesn't work because of the backlight class knob and
select being broken.
-Daniel
--
Daniel Vetter
Software
guess the hw guys
worked really hard to hide the snooping costs so that the gpu can benefit
from the massive bandwidth these caches can provide.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
49 matches
Mail list logo
