search for: l387

...dpa_device_index in dev. > > I followed the code in VFIO which creates char dev > vfio/$GROUP dynamically, e.g.: > > https://github.com/torvalds/linux/blob/b1da3acc781c/drivers/vfio/vfio.c#L2164-L2180 > https://github.com/torvalds/linux/blob/b1da3acc781c/drivers/vfio/vfio.c#L373-L387 > https://github.com/torvalds/linux/blob/b1da3acc781c/drivers/vfio/vfio.c#L1553 > > Is it something unwanted? Yes it is unwanted. This is some special pattern for vfio's unique needs. Since this has a struct device for each char dev instance please use the normal cdev_device_add()...

On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote: > +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v) > +{ > + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1, > + GFP_KERNEL); > +} Please don't use idr in new code, use xarray directly > +static int vhost_vdpa_probe(struct device *dev) > +{ > + struct vdpa_device *vdpa = dev_to_vdpa(dev);

On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote: > +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v) > +{ > + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1, > + GFP_KERNEL); > +} Please don't use idr in new code, use xarray directly > +static int vhost_vdpa_probe(struct device *dev) > +{ > + struct vdpa_device *vdpa = dev_to_vdpa(dev);

...s to rewrite the header so that's what we did. AOL has similar problems, btw. We currently rewrite emails from the following domains: google.com ebay.com paypal.com yahoo.com aol.com. FYI, the code that does this is here: https://github.com/biviosoftware/perl-Bivio/blob/master/Mail/Outgoing.pm#L387 (Trying not hijack and promote my own project, here, but then again > it is the reason I started using Xapian :) > > Things like this Yahoo change is one of the reasons I chose to take an > "archives first" approach to mailing lists with public-inbox. Email > gets...

...a char dev named vhost-vdpa/$vdpa_device_index in dev. I followed the code in VFIO which creates char dev vfio/$GROUP dynamically, e.g.: https://github.com/torvalds/linux/blob/b1da3acc781c/drivers/vfio/vfio.c#L2164-L2180 https://github.com/torvalds/linux/blob/b1da3acc781c/drivers/vfio/vfio.c#L373-L387 https://github.com/torvalds/linux/blob/b1da3acc781c/drivers/vfio/vfio.c#L1553 Is it something unwanted? Thanks for the review. Regards, Tiwei > > If so, why is there this: > > +static int vhost_vdpa_open(struct inode *inode, struct file *filep) > +{ > + struct vhost_vdpa *v;...

...this patch the function can return different > value(if there are differences between provided and calculated vrefresh). > > Quick examples where output of this function matters: > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387 Already looks quite sketchy due to rounding. > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42 msleep() is in no way accurate so looks rather sketchy as well. > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/t...

A few hours ago 20 addresses got unsubscribed from this list due to bounces caused by Yahoo's DMARC p=reject policy: https://help.yahoo.com/kb/SLN24050.html This breaks mailing lists. Yahoo are well aware of this, but don't seem to care: http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-breaks-mailing-lists.html The nearest Yahoo seem to come to useful advice is

...tainly not unacceptable. Given that armv7l is already treated in this way, it is not unreasonable to also support armv6l. How is this for a proposed solution? What if I add logic to llvm::ARM::getCanonicalArchName() <https://github.com/apple/swift-llvm/blob/stable/lib/Support/TargetParser.cpp#L387> that matches the trailing ‘l’ (or ‘b’) and treats it the same way that ‘el’ and ‘eb’ are now? This function would return v7 or v6 in the case of armv7l or armv6l, respectively (or, if it’s preferred, v7a or v6a). It seems like this is closer to the “correct” approach. It does show potentiall...

...an return different > > value(if there are differences between provided and calculated vrefresh). > > > > Quick examples where output of this function matters: > > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387 > > Already looks quite sketchy due to rounding. > > > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42 > > msleep() is in no way accurate so looks rather sketchy as well. > > > https://elixir.bootlin.com...

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > On 19.02.2020 21:35, Ville Syrjala wrote: > > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > > > Get rid of mode->vrefresh and just calculate it on demand. Saves > > a bit of space and avoids the cached value getting out of sync > > with reality. > > > > Mostly done

...rm_mode_vrefresh - after this patch the function can return different value(if there are differences between provided and calculated vrefresh). Quick examples where output of this function matters: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387 https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42 https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810 Regards Andrzej > >> >> Regards >> >> Andrzej >> >> >>>...