* [PATCH 12/26] pvr2fb: Convert pvr2fb_write() to use get_user_pages_fast()
From: Jan Kara @ 2013-10-02 14:27 UTC (permalink / raw)
To: LKML
Cc: linux-mm, Jan Kara, linux-fbdev, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1380724087-13927-1-git-send-email-jack@suse.cz>
CC: linux-fbdev@vger.kernel.org
CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
CC: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Signed-off-by: Jan Kara <jack@suse.cz>
---
drivers/video/pvr2fb.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
index df07860563e6..31e1345a88a8 100644
--- a/drivers/video/pvr2fb.c
+++ b/drivers/video/pvr2fb.c
@@ -686,11 +686,7 @@ static ssize_t pvr2fb_write(struct fb_info *info, const char *buf,
if (!pages)
return -ENOMEM;
- down_read(¤t->mm->mmap_sem);
- ret = get_user_pages(current, current->mm, (unsigned long)buf,
- nr_pages, WRITE, 0, pages, NULL);
- up_read(¤t->mm->mmap_sem);
-
+ ret = get_user_pages_fast((unsigned long)buf, nr_pages, WRITE, pages);
if (ret < nr_pages) {
nr_pages = ret;
ret = -EINVAL;
--
1.8.1.4
^ permalink raw reply related
* RE: [PATCH 1/2] hyperv-fb: add pci stub
From: KY Srinivasan @ 2013-10-02 14:29 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Haiyang Zhang, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:Hyper-V CORE AND..., open list:FRAMEBUFFER LAYER,
open list
In-Reply-To: <1380714911-6254-1-git-send-email-kraxel@redhat.com>
> -----Original Message-----
> From: Gerd Hoffmann [mailto:kraxel@redhat.com]
> Sent: Wednesday, October 02, 2013 4:55 AM
> Cc: Gerd Hoffmann; KY Srinivasan; Haiyang Zhang; Jean-Christophe Plagniol-
> Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...; open list:FRAMEBUFFER
> LAYER; open list
> Subject: [PATCH 1/2] hyperv-fb: add pci stub
>
> This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer
> driver will bind to the pci device then, so linux kernel and userspace
> know there is a proper kernel driver for the device active. lspci shows
> this for example:
>
> [root@dhcp231 ~]# lspci -vs8
> 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
> VGA (prog-if 00 [VGA controller])
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f8000000 (32-bit, non-prefetchable) [sizedM]
> Expansion ROM at <unassigned> [disabled]
> Kernel driver in use: hyperv_fb
>
> Another effect is that the xorg vesa driver will not attach to the
> device and thus the Xorg server will automatically use the fbdev
> driver instead.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/video/hyperv_fb.c | 40
> +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
> index 8ac99b8..8d456dc 100644
> --- a/drivers/video/hyperv_fb.c
> +++ b/drivers/video/hyperv_fb.c
> @@ -795,12 +795,21 @@ static int hvfb_remove(struct hv_device *hdev)
> }
>
>
> +static DEFINE_PCI_DEVICE_TABLE(pci_stub_id_table) = {
> + {
> + .vendor = PCI_VENDOR_ID_MICROSOFT,
> + .device = PCI_DEVICE_ID_HYPERV_VIDEO,
> + },
> + { /* end of list */ }
> +};
> +
> static const struct hv_vmbus_device_id id_table[] = {
> /* Synthetic Video Device GUID */
> {HV_SYNTHVID_GUID},
> {}
> };
>
> +MODULE_DEVICE_TABLE(pci, pci_stub_id_table);
> MODULE_DEVICE_TABLE(vmbus, id_table);
>
> static struct hv_driver hvfb_drv = {
> @@ -810,14 +819,43 @@ static struct hv_driver hvfb_drv = {
> .remove = hvfb_remove,
> };
>
> +static int hvfb_pci_stub_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + return 0;
> +}
> +
> +static void hvfb_pci_stub_remove(struct pci_dev *pdev)
> +{
> +}
> +
> +static struct pci_driver hvfb_pci_stub_driver = {
> + .name = KBUILD_MODNAME,
> + .id_table = pci_stub_id_table,
> + .probe = hvfb_pci_stub_probe,
> + .remove = hvfb_pci_stub_remove,
> +};
>
> static int __init hvfb_drv_init(void)
> {
> - return vmbus_driver_register(&hvfb_drv);
> + int ret;
> +
> + ret = vmbus_driver_register(&hvfb_drv);
> + if (ret != 0)
> + return ret;
> +
> + ret = pci_register_driver(&hvfb_pci_stub_driver);
> + if (ret != 0) {
> + vmbus_driver_unregister(&hvfb_drv);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static void __exit hvfb_drv_exit(void)
> {
> + pci_unregister_driver(&hvfb_pci_stub_driver);
> vmbus_driver_unregister(&hvfb_drv);
> }
>
> --
> 1.8.3.1
Gerd,
Thanks for doing this. This certainly will address some of the issues that are reported. I do have a question though - how would this work if we don't have PCI bus in the guest.
Regards,
K. Y
^ permalink raw reply
* [PATCH 1/2] simplefb: fix unmapping fb during destruction
From: David Herrmann @ 2013-10-02 14:58 UTC (permalink / raw)
To: linux-fbdev
Cc: Stephen Warren, linux-kernel, dri-devel, Tomi Valkeinen,
Alexandre Courbot, Jean-Christophe Plagniol-Villard
Unfortunately, fbdev does not create its own "struct device" for
framebuffers. Instead, it attaches to the device of the parent layer. This
has the side-effect that devm_* managed resources are not cleaned up on
framebuffer-destruction but rather during destruction of the
parent-device. In case of fbdev this might be too late, though.
remove_conflicting_framebuffer() may remove fbdev devices but keep the
parent device as it is.
Therefore, we now use plain ioremap() and unmap the framebuffer in the
fb_destroy() callback. Note that we must not free the device here as this
might race with the parent-device removal. Instead, we rely on
unregister_framebuffer() as barrier and we're safe.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
Hi
I know that simplefb was supposed to stay "as simple as possible" but I really
think this series is the last set of fixes I have. Unfortunately framebuffer DRM
handover is mandatory so we cannot ignore it in simplefb.
Both patches are not critical at all and are targeted at 3.13-rc1.
Thanks
David
drivers/video/simplefb.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..74b016c 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -66,8 +66,15 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
return 0;
}
+static void simplefb_destroy(struct fb_info *info)
+{
+ if (info->screen_base)
+ iounmap(info->screen_base);
+}
+
static struct fb_ops simplefb_ops = {
.owner = THIS_MODULE,
+ .fb_destroy = simplefb_destroy,
.fb_setcolreg = simplefb_setcolreg,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
@@ -212,8 +219,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = ioremap(info->fix.smem_start,
+ info->fix.smem_len);
if (!info->screen_base) {
framebuffer_release(info);
return -ENODEV;
@@ -223,6 +230,7 @@ static int simplefb_probe(struct platform_device *pdev)
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
+ iounmap(info->screen_base);
framebuffer_release(info);
return ret;
}
--
1.8.4
^ permalink raw reply related
* [PATCH 2/2] simplefb: use write-combined remapping
From: David Herrmann @ 2013-10-02 14:58 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, Tom Gundersen, Alexandre Courbot, Stephen Warren,
dri-devel, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
David Herrmann
In-Reply-To: <1380725919-1961-1-git-send-email-dh.herrmann@gmail.com>
Framebuffers shouldn't be cached and it is usually very uncommon to read
them. Therefore, use ioremap_wc() to get significant speed improvements on
systems which provide it. On all other systems it's aliased to
ioremap_nocache() which is also fine.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Tested-by: Tom Gundersen <teg@jklm.no>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
---
drivers/video/simplefb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 74b016c..64db54a 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -219,8 +219,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = ioremap(info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = ioremap_wc(info->fix.smem_start,
+ info->fix.smem_len);
if (!info->screen_base) {
framebuffer_release(info);
return -ENODEV;
--
1.8.4
^ permalink raw reply related
* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-10-02 15:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
Hi
On Tue, Sep 10, 2013 at 4:34 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 09/07/2013 06:25 AM, David Herrmann wrote:
>> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
> ...
>>> A related question: is it expected that simplefb should be
>>> significantly slower than efifb, or is that something worth looking
>>> into? My boot with simplefb is roughly five seconds slower than with
>>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>>> inteldrmfb when I see the oops (but not otherwise).
>>
>> That is probably related to the missing write-combine tag in ioremap.
>> Stephen, any objections to this attached patch?
>> Tom, if this solves the speed-issues, I will send it out once I get home.
>>
>> Thanks
>> David
>>
>> (Patch also attached in case of new-lines issues)
>>
>> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
>> From: David Herrmann <dh.herrmann@gmail.com>
>> Date: Sat, 7 Sep 2013 14:22:01 +0200
>> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>>
>> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
>> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
>> introduce it along the way. Note that ioremap_wc() is aliases to
>> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
>> architectures to either provide it or use the same alias.
>
> OK, that works fine on the Raspberry Pi too, so,
> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
Back from the US and all patches sent out. Sorry for the delay. If I
missed something, please let me know.
Thanks for your feedback!
David
^ permalink raw reply
* Re: [PATCH 1/2] simplefb: fix unmapping fb during destruction
From: Stephen Warren @ 2013-10-02 16:16 UTC (permalink / raw)
To: David Herrmann
Cc: linux-fbdev, linux-kernel, Tom Gundersen, Alexandre Courbot,
dri-devel, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
In-Reply-To: <1380725919-1961-1-git-send-email-dh.herrmann@gmail.com>
On 10/02/2013 08:58 AM, David Herrmann wrote:
> Unfortunately, fbdev does not create its own "struct device" for
> framebuffers. Instead, it attaches to the device of the parent layer. This
> has the side-effect that devm_* managed resources are not cleaned up on
> framebuffer-destruction but rather during destruction of the
> parent-device. In case of fbdev this might be too late, though.
> remove_conflicting_framebuffer() may remove fbdev devices but keep the
> parent device as it is.
>
> Therefore, we now use plain ioremap() and unmap the framebuffer in the
> fb_destroy() callback. Note that we must not free the device here as this
> might race with the parent-device removal. Instead, we rely on
> unregister_framebuffer() as barrier and we're safe.
So, once the .fb_destroy callback has been executed, there's no other
callback to resurrect it? The framebuffer itself is still registered
until the device's remove, yet after .fb_destroy, the memory is
unmapped, which would be dangerous if the FB can be re-started.
If that's not an issue, this patch seems fine, so
Acked-by: Stephen Warren <swarren@nvidia.com>
> I know that simplefb was supposed to stay "as simple as possible" but I really
> think this series is the last set of fixes I have. Unfortunately framebuffer DRM
> handover is mandatory so we cannot ignore it in simplefb.
I don't think this patch adds any significant complexity, so I'm not
worried at least.
^ permalink raw reply
* Re: [PATCH 1/2] simplefb: fix unmapping fb during destruction
From: David Herrmann @ 2013-10-02 16:23 UTC (permalink / raw)
To: Stephen Warren
Cc: linux-fbdev@vger.kernel.org, linux-kernel, Tom Gundersen,
Alexandre Courbot, dri-devel@lists.freedesktop.org,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
In-Reply-To: <524C46E2.5040804@wwwdotorg.org>
Hi
On Wed, Oct 2, 2013 at 6:16 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/02/2013 08:58 AM, David Herrmann wrote:
>> Unfortunately, fbdev does not create its own "struct device" for
>> framebuffers. Instead, it attaches to the device of the parent layer. This
>> has the side-effect that devm_* managed resources are not cleaned up on
>> framebuffer-destruction but rather during destruction of the
>> parent-device. In case of fbdev this might be too late, though.
>> remove_conflicting_framebuffer() may remove fbdev devices but keep the
>> parent device as it is.
>>
>> Therefore, we now use plain ioremap() and unmap the framebuffer in the
>> fb_destroy() callback. Note that we must not free the device here as this
>> might race with the parent-device removal. Instead, we rely on
>> unregister_framebuffer() as barrier and we're safe.
>
> So, once the .fb_destroy callback has been executed, there's no other
> callback to resurrect it? The framebuffer itself is still registered
> until the device's remove, yet after .fb_destroy, the memory is
> unmapped, which would be dangerous if the FB can be re-started.
fbdev lifetime tracking is weird.. ->fb_destroy() is called by
unregister_framebuffer() _after_ it got unlinked. So no, the
framebuffer is gone and cannot be resurrected. However, the
unregistered/dead fbdev object itself stays around until you call
framebuffer_release(). We cannot call it from fb_destroy(), though as
the platform_data in your platform device still points to the fbdev
device. Therefore we keep it and wait for the platform-driver to be
removed which then again calls unregister_framebuffer() (which will
immediately return as the fbdev device is not registered) and then you
can finally call framebuffer_release().
Note that even though there's fb_get_info() and fb_put_info(), both
are not exported and never used. So there is *no* fbdev ref-counting
(which would be horribly broken anyway) and the driver is the sole
owner of the fbdev object.
> If that's not an issue, this patch seems fine, so
> Acked-by: Stephen Warren <swarren@nvidia.com>
Thanks!
>> I know that simplefb was supposed to stay "as simple as possible" but I really
>> think this series is the last set of fixes I have. Unfortunately framebuffer DRM
>> handover is mandatory so we cannot ignore it in simplefb.
>
> I don't think this patch adds any significant complexity, so I'm not
> worried at least.
Good to hear!
Thanks
David
^ permalink raw reply
* [PATCH v2] efifb: prevent null-deref when iterating dmi_list
From: David Herrmann @ 2013-10-02 16:40 UTC (permalink / raw)
To: linux-fbdev
Cc: James Bates, linux-kernel, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, David Herrmann, James Bates
The dmi_list array is initialized using gnu designated initializers, and
therefore may contain fewer explicitly defined entries as there are
elements in it. This is because the enum above with M_xyz constants
contains more items than the designated initializer. Those elements not
explicitly initialized are implicitly set to 0.
Now efifb_setup() loops through all these array elements, and performs
a strcmp on each item. For non explicitly initialized elements this will
be a null pointer:
This patch swaps the check order in the if statement, thus checks first
whether dmi_list[i].base is null.
Signed-off-by: James Bates <james.h.bates@yahoo.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
Hi
As James didn't respond to the last emails, I just rebased the patch and resent
it. The efi M_xyz constants were moved to x86-sysfb so if anyone wants to remove
unused bits, please send a separate patch to LKML and x86-ML. This patch just
fixes the NULL-deref.
Thanks
David
drivers/video/efifb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 7f9ff75..fcb9500 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -108,8 +108,8 @@ static int efifb_setup(char *options)
if (!*this_opt) continue;
for (i = 0; i < M_UNKNOWN; i++) {
- if (!strcmp(this_opt, efifb_dmi_list[i].optname) &&
- efifb_dmi_list[i].base != 0) {
+ if (efifb_dmi_list[i].base != 0 &&
+ !strcmp(this_opt, efifb_dmi_list[i].optname)) {
screen_info.lfb_base = efifb_dmi_list[i].base;
screen_info.lfb_linelength = efifb_dmi_list[i].stride;
screen_info.lfb_width = efifb_dmi_list[i].width;
--
1.8.4
^ permalink raw reply related
* [PATCH v3] efifb: prevent null-deref when iterating dmi_list
From: David Herrmann @ 2013-10-02 16:43 UTC (permalink / raw)
To: linux-fbdev
Cc: James Bates, linux-kernel, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, David Herrmann
In-Reply-To: <1380732056-5387-1-git-send-email-dh.herrmann@gmail.com>
From: James Bates <james.h.bates@gmail.com>
The dmi_list array is initialized using gnu designated initializers, and
therefore may contain fewer explicitly defined entries as there are
elements in it. This is because the enum above with M_xyz constants
contains more items than the designated initializer. Those elements not
explicitly initialized are implicitly set to 0.
Now efifb_setup() loops through all these array elements, and performs
a strcmp on each item. For non explicitly initialized elements this will
be a null pointer:
This patch swaps the check order in the if statement, thus checks first
whether dmi_list[i].base is null.
Signed-off-by: James Bates <james.h.bates@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
v3: fixes the "Author" field and James' email address
drivers/video/efifb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 7f9ff75..fcb9500 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -108,8 +108,8 @@ static int efifb_setup(char *options)
if (!*this_opt) continue;
for (i = 0; i < M_UNKNOWN; i++) {
- if (!strcmp(this_opt, efifb_dmi_list[i].optname) &&
- efifb_dmi_list[i].base != 0) {
+ if (efifb_dmi_list[i].base != 0 &&
+ !strcmp(this_opt, efifb_dmi_list[i].optname)) {
screen_info.lfb_base = efifb_dmi_list[i].base;
screen_info.lfb_linelength = efifb_dmi_list[i].stride;
screen_info.lfb_width = efifb_dmi_list[i].width;
--
1.8.4
^ permalink raw reply related
* Re: [PATCH] amba: Ensure drvdata is NULL
From: Russell King - ARM Linux @ 2013-10-02 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b2479137287fa8dfda3089ca0cb9fba8c4b1f1d.1380524337.git.michal.simek@xilinx.com>
On Mon, Sep 30, 2013 at 08:59:06AM +0200, Michal Simek wrote:
> This patch is inpired by the patch for drvdata
> "device-core: Ensure drvdata = NULL when no driver is bound"
> (sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
>
> Also it fixes all occurences in drivers.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> This patch has been sent as RFC in this thread.
> http://lkml.org/lkml/2013/9/4/393
Why not have the driver core do this? Then it gets applied to all bus
types uniformly.
Thanks.
^ permalink raw reply
* RE: [PATCH 1/2] hyperv-fb: add pci stub
From: Haiyang Zhang @ 2013-10-02 20:42 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: KY Srinivasan, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:Hyper-V CORE AND..., open list:FRAMEBUFFER LAYER,
open list
In-Reply-To: <1380714911-6254-1-git-send-email-kraxel@redhat.com>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Gerd Hoffmann
> Sent: Wednesday, October 2, 2013 7:55 AM
> Cc: Gerd Hoffmann; KY Srinivasan; Haiyang Zhang; Jean-Christophe Plagniol-
> Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...; open
> list:FRAMEBUFFER LAYER; open list
> Subject: [PATCH 1/2] hyperv-fb: add pci stub
>
> This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer driver
> will bind to the pci device then, so linux kernel and userspace know there is a
> proper kernel driver for the device active. lspci shows this for example:
>
> [root@dhcp231 ~]# lspci -vs8
> 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
> VGA (prog-if 00 [VGA controller])
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f8000000 (32-bit, non-prefetchable) [sizedM]
> Expansion ROM at <unassigned> [disabled]
> Kernel driver in use: hyperv_fb
>
> Another effect is that the xorg vesa driver will not attach to the device and
> thus the Xorg server will automatically use the fbdev driver instead.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Haiyang Zhang <haiyangz@microsoft.com>
Thank you for fixing this!
- Haiyang
^ permalink raw reply
* RE: [PATCH 2/2] hyperv-fb: add blanking support
From: Haiyang Zhang @ 2013-10-02 20:43 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: KY Srinivasan, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:Hyper-V CORE AND..., open list:FRAMEBUFFER LAYER,
open list
In-Reply-To: <1380714911-6254-2-git-send-email-kraxel@redhat.com>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Gerd Hoffmann
> Sent: Wednesday, October 2, 2013 7:55 AM
> Cc: Gerd Hoffmann; KY Srinivasan; Haiyang Zhang; Jean-Christophe Plagniol-
> Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...; open
> list:FRAMEBUFFER LAYER; open list
> Subject: [PATCH 2/2] hyperv-fb: add blanking support
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Haiyang Zhang <haiyangz@microsoft.com>
^ permalink raw reply
* Re: [PATCH] amba: Ensure drvdata is NULL
From: Michal Simek @ 2013-10-03 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131002202521.GU12758@n2100.arm.linux.org.uk>
On 10/02/2013 10:25 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 30, 2013 at 08:59:06AM +0200, Michal Simek wrote:
>> This patch is inpired by the patch for drvdata
>> "device-core: Ensure drvdata = NULL when no driver is bound"
>> (sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
>>
>> Also it fixes all occurences in drivers.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>> This patch has been sent as RFC in this thread.
>> http://lkml.org/lkml/2013/9/4/393
>
> Why not have the driver core do this? Then it gets applied to all bus
> types uniformly.
ok - I have checked that path and it should be already done
in really_probe function which calls amba_probe() and then driver probe function.
It means that the patch should contain just "amba_set_drvdata(dev, NULL);"
removal and not touching bus.c file.
Thanks,
Michal
^ permalink raw reply
* [PATCH 9/9] video: amba-clcd: Remove unnecessary amba_set_drvdata()
From: Michal Simek @ 2013-10-03 9:46 UTC (permalink / raw)
To: linux-kernel, monstr
Cc: Russell King, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev
In-Reply-To: <27e289763bbcb7d10f84081543cfc3a4dc770398.1380793579.git.michal.simek@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
Driver core clears the driver data to NULL after device_release
or on probe failure, so just remove it from here.
Driver core change:
"device-core: Ensure drvdata = NULL when no driver is bound"
(sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/video/amba-clcd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..0bab6ab 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -594,8 +594,6 @@ static int clcdfb_remove(struct amba_device *dev)
{
struct clcd_fb *fb = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
clcdfb_disable(fb);
unregister_framebuffer(&fb->fb);
if (fb->fb.cmap.len)
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* looking for loan
From: Aijaz Lending @ 2013-10-03 20:16 UTC (permalink / raw)
To: linux-fbdev
Do you have a firm or company that need loan to start up a business or need,personal loan, Debt consolidation? For more information,Contact us now for a guarantee loan with low interest rate. We will provide you with loan to meet your needs. For more information contact us with the following information's.
Full name:
country:
Address:
Phone Number:
Amount needed:
Duration of loan:
sg.loan.sg@outlook.com
Kind regards
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: remove Richard Purdie as backlight maintainer
From: Andrew Morton @ 2013-10-03 23:20 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-kernel, linux-fbdev, 'Richard Purdie',
'Thierry Reding', 'Tomi Valkeinen',
'Laurent Pinchart', 'Michael Hennerich',
'Milo Kim', 'Daniel Jeong'
In-Reply-To: <017f01cebb35$f6a82ac0$e3f88040$%han@samsung.com>
On Fri, 27 Sep 2013 12:59:28 +0900 Jingoo Han <jg1.han@samsung.com> wrote:
> Remove Richard Purdie as backlight subsystem maintainer, since he
> is not responding for a few years.
It's nice to give a person a ./CREDITS entry when we remove them from
./MAINTAINERS.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: remove Richard Purdie as backlight maintainer
From: Jingoo Han @ 2013-10-03 23:50 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Richard Purdie',
'Thierry Reding', 'Tomi Valkeinen',
'Laurent Pinchart', 'Michael Hennerich',
'Milo Kim', 'Daniel Jeong', 'Jingoo Han'
In-Reply-To: <20131003162048.d4be6510f36da5c61dc61c43@linux-foundation.org>
On Friday, October 04, 2013 8:21 AM, Andrew Morton wrote:
> On Fri, 27 Sep 2013 12:59:28 +0900 Jingoo Han <jg1.han@samsung.com> wrote:
>
> > Remove Richard Purdie as backlight subsystem maintainer, since he
> > is not responding for a few years.
>
> It's nice to give a person a ./CREDITS entry when we remove them from
> ./MAINTAINERS.
However, Richard Purdie still remains as maintainers of other two entries
as below:
In this case, is it still necessary give him a ./CREDITS entry?
ARM/CORGI MACHINE SUPPORT
M: Richard Purdie <rpurdie@rpsys.net>
LED SUBSYSTEM
M: Bryan Wu <cooloney@gmail.com>
M: Richard Purdie <rpurdie@rpsys.net>
Best regards,
Jingoo Han
^ permalink raw reply
* [PATCH V2] MAINTAINERS: remove Richard Purdie as backlight maintainer
From: Jingoo Han @ 2013-10-04 0:13 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Richard Purdie',
'Jingoo Han', 'Thierry Reding',
'Tomi Valkeinen', 'Laurent Pinchart',
'Michael Hennerich', 'Milo Kim',
'Daniel Jeong'
Remove Richard Purdie as backlight subsystem maintainer, since he
is not responding for a few years.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
---
CREDITS | 5 +++++
MAINTAINERS | 1 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/CREDITS b/CREDITS
index 0640e16..dfe3cf8 100644
--- a/CREDITS
+++ b/CREDITS
@@ -2895,6 +2895,11 @@ S: Framewood Road
S: Wexham SL3 6PJ
S: United Kingdom
+N: Richard Purdie
+E: rpurdie@rpsys.net
+D: Backlight subsystem maintainer
+S: USA
+
N: Daniel Quinlan
E: quinlan@pathname.com
W: http://www.pathname.com/~quinlan/
diff --git a/MAINTAINERS b/MAINTAINERS
index 5678de3..3a967c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1651,7 +1651,6 @@ S: Maintained
F: drivers/net/wireless/b43legacy/
BACKLIGHT CLASS/SUBSYSTEM
-M: Richard Purdie <rpurdie@rpsys.net>
M: Jingoo Han <jg1.han@samsung.com>
S: Maintained
F: drivers/video/backlight/
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: remove Richard Purdie as backlight maintainer
From: Andrew Morton @ 2013-10-04 0:43 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-kernel, linux-fbdev, 'Richard Purdie',
'Thierry Reding', 'Tomi Valkeinen',
'Laurent Pinchart', 'Michael Hennerich',
'Milo Kim', 'Daniel Jeong'
In-Reply-To: <003801cec093$6b3c1bf0$41b453d0$%han@samsung.com>
On Fri, 04 Oct 2013 08:50:57 +0900 Jingoo Han <jg1.han@samsung.com> wrote:
> On Friday, October 04, 2013 8:21 AM, Andrew Morton wrote:
> > On Fri, 27 Sep 2013 12:59:28 +0900 Jingoo Han <jg1.han@samsung.com> wrote:
> >
> > > Remove Richard Purdie as backlight subsystem maintainer, since he
> > > is not responding for a few years.
> >
> > It's nice to give a person a ./CREDITS entry when we remove them from
> > ./MAINTAINERS.
>
> However, Richard Purdie still remains as maintainers of other two entries
> as below:
> In this case, is it still necessary give him a ./CREDITS entry?
Necessary? No. Nice? Yes ;) I like to think that it reduces any of
the sting from being removed from MAINTAINERS. Plus it is more
accurate and costs nothing.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: remove Richard Purdie as backlight maintainer
From: Richard Purdie @ 2013-10-04 9:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Jingoo Han, linux-kernel, linux-fbdev, 'Thierry Reding',
'Tomi Valkeinen', 'Laurent Pinchart',
'Michael Hennerich', 'Milo Kim',
'Daniel Jeong'
In-Reply-To: <20131003174315.d9aa8af7.akpm@linux-foundation.org>
On Thu, 2013-10-03 at 17:43 -0700, Andrew Morton wrote:
> On Fri, 04 Oct 2013 08:50:57 +0900 Jingoo Han <jg1.han@samsung.com> wrote:
>
> > On Friday, October 04, 2013 8:21 AM, Andrew Morton wrote:
> > > On Fri, 27 Sep 2013 12:59:28 +0900 Jingoo Han <jg1.han@samsung.com> wrote:
> > >
> > > > Remove Richard Purdie as backlight subsystem maintainer, since he
> > > > is not responding for a few years.
> > >
> > > It's nice to give a person a ./CREDITS entry when we remove them from
> > > ./MAINTAINERS.
> >
> > However, Richard Purdie still remains as maintainers of other two entries
> > as below:
> > In this case, is it still necessary give him a ./CREDITS entry?
>
> Necessary? No. Nice? Yes ;) I like to think that it reduces any of
> the sting from being removed from MAINTAINERS. Plus it is more
> accurate and costs nothing.
It is sad to be removed from there but equally, I haven't had the time
to spend on it for a while and it is justified. I am still around, I
have been reading some of the patches, there are just other things which
are more in need of my time (the Yocto Project primarily). I'd done what
I'd set out to do with the backlight/leds subsystems and its time to let
others take them forward. So a credits entry sounds nice and probably
more appropriate now, thanks :)
Cheers,
Richard
^ permalink raw reply
* You've won a Prize
From: Microsoft Iberica SL @ 2013-10-05 17:40 UTC (permalink / raw)
To: linux-fbdev
You've won a Prize
MICROSOFT IBERICA SL"
YOU 'VE WON.
ATTN:MICROSOFT IBERICA SL
Your email has won (EUR244,000,00)
(TWO HUNDRED AND FOURTY FOUR THOUSAND EURO)
Batch number:XL73276498AM
Ref number:QR352899526KC
This is a millennium scientific computer game in which
email addresses were used.It is a promotional program aimed at
encouraging internet users,therefore you do not need to buy ticket to enter
for it.
For further development,clarification and procedure please
Contact:Dr Eduardo Sanchez,
Email contact:payingroll446@yahoo.com.hk
^ permalink raw reply
* Re: [PATCH V5 1/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Kukjin Kim @ 2013-10-06 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <524AE9BC.6060103@ti.com>
On 10/02/13 00:26, Kishon Vijay Abraham I wrote:
> On Wednesday 02 October 2013 02:43 AM, Sylwester Nawrocki wrote:
>> On 10/01/2013 07:28 AM, Kishon Vijay Abraham I wrote:
>>> On Sunday 29 September 2013 12:57 AM, Sylwester Nawrocki wrote:
>>>>> Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
>>>>>
>>>>> Signed-off-by: Sylwester Nawrocki<s.nawrocki@samsung.com>
>>>>> Signed-off-by: Kyungmin Park<kyungmin.park@samsung.com>
>>>>> Acked-by: Felipe Balbi<balbi@ti.com>
>>>
>>> Can this patch be taken through exynos dt tree?
>>
>> Yes, that makes more sense indeed. Kukjin, would you mind taking
>> this patch to your tree ?
>
Sure. Applied this whole series.
> FWIW
> Acked-by: Kishon Vijay Abraham I<kishon@ti.com>
>>
Thanks,
Kukjin
^ permalink raw reply
* Re: [PATCH V5 1/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Kukjin Kim @ 2013-10-06 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5250AA3F.6030701@samsung.com>
On 10/06/13 09:09, Kukjin Kim wrote:
>
> On 10/02/13 00:26, Kishon Vijay Abraham I wrote:
>> On Wednesday 02 October 2013 02:43 AM, Sylwester Nawrocki wrote:
>>> On 10/01/2013 07:28 AM, Kishon Vijay Abraham I wrote:
>>>> On Sunday 29 September 2013 12:57 AM, Sylwester Nawrocki wrote:
>>>>>> Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
>>>>>>
>>>>>> Signed-off-by: Sylwester Nawrocki<s.nawrocki@samsung.com>
>>>>>> Signed-off-by: Kyungmin Park<kyungmin.park@samsung.com>
>>>>>> Acked-by: Felipe Balbi<balbi@ti.com>
>>>>
>>>> Can this patch be taken through exynos dt tree?
>>>
>>> Yes, that makes more sense indeed. Kukjin, would you mind taking
>>> this patch to your tree ?
>>
> Sure. Applied this whole series.
>
Oops, sorry. Only this patch ;-)
>> FWIW
>> Acked-by: Kishon Vijay Abraham I<kishon@ti.com>
>>>
Thanks,
Kukjin
^ permalink raw reply
* Re: [PATCH 1/2] hyperv-fb: add pci stub
From: Gerd Hoffmann @ 2013-10-07 6:50 UTC (permalink / raw)
To: KY Srinivasan
Cc: Haiyang Zhang, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:Hyper-V CORE AND..., open list:FRAMEBUFFER LAYER,
open list
In-Reply-To: <465ef0cb45e04bcc94c4788c0d930c4d@SN2PR03MB061.namprd03.prod.outlook.com>
On Mi, 2013-10-02 at 14:29 +0000, KY Srinivasan wrote:
>
> > This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer
> > driver will bind to the pci device then, so linux kernel and userspace
> > know there is a proper kernel driver for the device active. lspci shows
> > this for example:
> Gerd,
>
> Thanks for doing this. This certainly will address some of the issues that are reported. I do have a question though - how would this work if we don't have PCI bus in the guest.
The hyperv framebuffer driver wouldn't work in the first place then as
it looks up the framebuffer address in pci config space (see hvfb_getmem
function).
cheers,
Gerd
^ permalink raw reply
* RE: [RFC PATCH 1/4] mipi-dsi-bus: add MIPI DSI bus support
From: Bert Kenward @ 2013-10-07 10:47 UTC (permalink / raw)
To: Andrzej Hajda, Laurent Pinchart
Cc: linux-fbdev@vger.kernel.org, Kyungmin Park,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
In-Reply-To: <1380032596-18612-2-git-send-email-a.hajda@samsung.com>
T24gVHVlc2RheSBTZXB0ZW1iZXIgMjQgMjAxMyBhdCAxNToyMywgQW5kcnplaiBIYWpkYSB3cm90
ZToNCj4gTUlQSSBEU0kgaXMgYSBoaWdoLXNwZWVkIHNlcmlhbCBpbnRlcmZhY2UgdG8gdHJhbnNt
aXQNCj4gZGF0YSBmcm9tL3RvIGhvc3QgdG8gZGlzcGxheSBtb2R1bGUuDQo+IA0KPiBTaWduZWQt
b2ZmLWJ5OiBBbmRyemVqIEhhamRhIDxhLmhhamRhQHNhbXN1bmcuY29tPg0KPiBTaWduZWQtb2Zm
LWJ5OiBLeXVuZ21pbiBQYXJrIDxreXVuZ21pbi5wYXJrQHNhbXN1bmcuY29tPg0KPiAtLS0NCj4g
IGRyaXZlcnMvdmlkZW8vZGlzcGxheS9LY29uZmlnICAgICAgICB8ICAgNCArDQo+ICBkcml2ZXJz
L3ZpZGVvL2Rpc3BsYXkvTWFrZWZpbGUgICAgICAgfCAgIDEgKw0KPiAgZHJpdmVycy92aWRlby9k
aXNwbGF5L21pcGktZHNpLWJ1cy5jIHwgMzMyDQo+ICsrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrDQo+ICBpbmNsdWRlL3ZpZGVvL2Rpc3BsYXkuaCAgICAgICAgICAgICAgfCAgIDMg
Kw0KPiAgaW5jbHVkZS92aWRlby9taXBpLWRzaS1idXMuaCAgICAgICAgIHwgMTQ0ICsrKysrKysr
KysrKysrKw0KPiAgNSBmaWxlcyBjaGFuZ2VkLCA0ODQgaW5zZXJ0aW9ucygrKQ0KDQo8c25pcHBl
ZCBhcyBmYXIgYXMgbWlwaS1kc2ktYnVzLmgNCg0KPiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS92aWRl
by9taXBpLWRzaS1idXMuaCBiL2luY2x1ZGUvdmlkZW8vbWlwaS1kc2ktYnVzLmgNCj4gbmV3IGZp
bGUgbW9kZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAwMC4uYTc4NzkyZA0KPiAtLS0gL2Rldi9udWxs
DQo+ICsrKyBiL2luY2x1ZGUvdmlkZW8vbWlwaS1kc2ktYnVzLmgNCj4gQEAgLTAsMCArMSwxNDQg
QEANCj4gKy8qDQo+ICsgKiBNSVBJIERTSSBCdXMNCj4gKyAqDQo+ICsgKiBDb3B5cmlnaHQgKEMp
IDIwMTMsIFNhbXN1bmcgRWxlY3Ryb25pY3MsIENvLiwgTHRkLg0KPiArICogQW5kcnplaiBIYWpk
YSA8YS5oYWpkYUBzYW1zdW5nLmNvbT4NCj4gKyAqDQo+ICsgKiBUaGlzIHByb2dyYW0gaXMgZnJl
ZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KPiArICog
aXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJz
aW9uIDIgYXMNCj4gKyAqIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
Lg0KPiArICovDQo+ICsNCj4gKyNpZm5kZWYgX19NSVBJX0RTSV9CVVNfSF9fDQo+ICsjZGVmaW5l
IF9fTUlQSV9EU0lfQlVTX0hfXw0KPiArDQo+ICsjaW5jbHVkZSA8bGludXgvZGV2aWNlLmg+DQo+
ICsjaW5jbHVkZSA8dmlkZW8vdmlkZW9tb2RlLmg+DQo+ICsNCj4gK3N0cnVjdCBtaXBpX2RzaV9i
dXM7DQo+ICtzdHJ1Y3QgbWlwaV9kc2lfZGV2aWNlOw0KPiArDQo+ICtzdHJ1Y3QgbWlwaV9kc2lf
YnVzX29wcyB7DQo+ICsJaW50ICgqc2V0X3Bvd2VyKShzdHJ1Y3QgbWlwaV9kc2lfYnVzICpidXMs
IHN0cnVjdCBtaXBpX2RzaV9kZXZpY2UNCj4gKmRldiwNCj4gKwkJCSBib29sIG9uKTsNCj4gKwlp
bnQgKCpzZXRfc3RyZWFtKShzdHJ1Y3QgbWlwaV9kc2lfYnVzICpidXMsIHN0cnVjdCBtaXBpX2Rz
aV9kZXZpY2UNCj4gKmRldiwNCj4gKwkJCSAgYm9vbCBvbik7DQo+ICsJaW50ICgqdHJhbnNmZXIp
KHN0cnVjdCBtaXBpX2RzaV9idXMgKmJ1cywgc3RydWN0IG1pcGlfZHNpX2RldmljZQ0KPiAqZGV2
LA0KPiArCQkJdTggdHlwZSwgY29uc3QgdTggKnR4X2J1Ziwgc2l6ZV90IHR4X2xlbiwgdTggKnJ4
X2J1ZiwNCj4gKwkJCXNpemVfdCByeF9sZW4pOw0KPiArfTsNCj4gKw0KPiArI2RlZmluZSBEU0lf
TU9ERV9WSURFTwkJCSgxIDw8IDApDQo+ICsjZGVmaW5lIERTSV9NT0RFX1ZJREVPX0JVUlNUCQko
MSA8PCAxKQ0KPiArI2RlZmluZSBEU0lfTU9ERV9WSURFT19TWU5DX1BVTFNFCSgxIDw8IDIpDQo+
ICsjZGVmaW5lIERTSV9NT0RFX1ZJREVPX0FVVE9fVkVSVAkoMSA8PCAzKQ0KPiArI2RlZmluZSBE
U0lfTU9ERV9WSURFT19IU0UJCSgxIDw8IDQpDQo+ICsjZGVmaW5lIERTSV9NT0RFX1ZJREVPX0hG
UAkJKDEgPDwgNSkNCj4gKyNkZWZpbmUgRFNJX01PREVfVklERU9fSEJQCQkoMSA8PCA2KQ0KPiAr
I2RlZmluZSBEU0lfTU9ERV9WSURFT19IU0EJCSgxIDw8IDcpDQo+ICsjZGVmaW5lIERTSV9NT0RF
X1ZTWU5DX0ZMVVNICQkoMSA8PCA4KQ0KPiArI2RlZmluZSBEU0lfTU9ERV9FT1RfUEFDS0VUCQko
MSA8PCA5KQ0KPiArDQo+ICtlbnVtIG1pcGlfZHNpX3BpeGVsX2Zvcm1hdCB7DQo+ICsJRFNJX0ZN
VF9SR0I4ODgsDQo+ICsJRFNJX0ZNVF9SR0I2NjYsDQo+ICsJRFNJX0ZNVF9SR0I2NjZfUEFDS0VE
LA0KPiArCURTSV9GTVRfUkdCNTY1LA0KPiArfTsNCj4gKw0KPiArc3RydWN0IG1pcGlfZHNpX2lu
dGVyZmFjZV9wYXJhbXMgew0KPiArCWVudW0gbWlwaV9kc2lfcGl4ZWxfZm9ybWF0IGZvcm1hdDsN
Cj4gKwl1bnNpZ25lZCBsb25nIG1vZGU7DQo+ICsJdW5zaWduZWQgbG9uZyBoc19jbGtfZnJlcTsN
Cj4gKwl1bnNpZ25lZCBsb25nIGVzY19jbGtfZnJlcTsNCj4gKwl1bnNpZ25lZCBjaGFyIGRhdGFf
bGFuZXM7DQo+ICsJdW5zaWduZWQgY2hhciBjbWRfYWxsb3c7DQo+ICt9Ow0KPiArDQo+ICtzdHJ1
Y3QgbWlwaV9kc2lfYnVzIHsNCj4gKwlzdHJ1Y3QgZGV2aWNlICpkZXY7DQo+ICsJY29uc3Qgc3Ry
dWN0IG1pcGlfZHNpX2J1c19vcHMgKm9wczsNCj4gK307DQo+ICsNCj4gKyNkZWZpbmUgTUlQSV9E
U0lfTU9EVUxFX1BSRUZJWAkJIm1pcGktZHNpOiINCj4gKyNkZWZpbmUgTUlQSV9EU0lfTkFNRV9T
SVpFCQkzMg0KPiArDQo+ICtzdHJ1Y3QgbWlwaV9kc2lfZGV2aWNlX2lkIHsNCj4gKwljaGFyIG5h
bWVbTUlQSV9EU0lfTkFNRV9TSVpFXTsNCj4gKwlfX2tlcm5lbF91bG9uZ190IGRyaXZlcl9kYXRh
CS8qIERhdGEgcHJpdmF0ZSB0byB0aGUgZHJpdmVyICovDQo+ICsJCQlfX2FsaWduZWQoc2l6ZW9m
KF9fa2VybmVsX3Vsb25nX3QpKTsNCj4gK307DQo+ICsNCj4gK3N0cnVjdCBtaXBpX2RzaV9kZXZp
Y2Ugew0KPiArCWNoYXIgbmFtZVtNSVBJX0RTSV9OQU1FX1NJWkVdOw0KPiArCWludCBpZDsNCj4g
KwlzdHJ1Y3QgZGV2aWNlIGRldjsNCj4gKw0KPiArCWNvbnN0IHN0cnVjdCBtaXBpX2RzaV9kZXZp
Y2VfaWQgKmlkX2VudHJ5Ow0KPiArCXN0cnVjdCBtaXBpX2RzaV9idXMgKmJ1czsNCj4gKwlzdHJ1
Y3QgdmlkZW9tb2RlIHZtOw0KPiArCXN0cnVjdCBtaXBpX2RzaV9pbnRlcmZhY2VfcGFyYW1zIHBh
cmFtczsNCj4gK307DQo+ICsNCj4gKyNkZWZpbmUgdG9fbWlwaV9kc2lfZGV2aWNlKGQpCWNvbnRh
aW5lcl9vZihkLCBzdHJ1Y3QNCj4gbWlwaV9kc2lfZGV2aWNlLCBkZXYpDQo+ICsNCj4gK2ludCBt
aXBpX2RzaV9kZXZpY2VfcmVnaXN0ZXIoc3RydWN0IG1pcGlfZHNpX2RldmljZSAqZGV2LA0KPiAr
CQkJICAgICBzdHJ1Y3QgbWlwaV9kc2lfYnVzICpidXMpOw0KPiArdm9pZCBtaXBpX2RzaV9kZXZp
Y2VfdW5yZWdpc3RlcihzdHJ1Y3QgbWlwaV9kc2lfZGV2aWNlICpkZXYpOw0KPiArDQo+ICtzdHJ1
Y3QgbWlwaV9kc2lfZHJpdmVyIHsNCj4gKwlpbnQoKnByb2JlKShzdHJ1Y3QgbWlwaV9kc2lfZGV2
aWNlICopOw0KPiArCWludCgqcmVtb3ZlKShzdHJ1Y3QgbWlwaV9kc2lfZGV2aWNlICopOw0KPiAr
CXN0cnVjdCBkZXZpY2VfZHJpdmVyIGRyaXZlcjsNCj4gKwljb25zdCBzdHJ1Y3QgbWlwaV9kc2lf
ZGV2aWNlX2lkICppZF90YWJsZTsNCj4gK307DQo+ICsNCj4gKyNkZWZpbmUgdG9fbWlwaV9kc2lf
ZHJpdmVyKGQpCWNvbnRhaW5lcl9vZihkLCBzdHJ1Y3QNCj4gbWlwaV9kc2lfZHJpdmVyLCBkcml2
ZXIpDQo+ICsNCj4gK2ludCBtaXBpX2RzaV9kcml2ZXJfcmVnaXN0ZXIoc3RydWN0IG1pcGlfZHNp
X2RyaXZlciAqZHJ2KTsNCj4gK3ZvaWQgbWlwaV9kc2lfZHJpdmVyX3VucmVnaXN0ZXIoc3RydWN0
IG1pcGlfZHNpX2RyaXZlciAqZHJ2KTsNCj4gKw0KPiArc3RhdGljIGlubGluZSB2b2lkICptaXBp
X2RzaV9nZXRfZHJ2ZGF0YShjb25zdCBzdHJ1Y3QgbWlwaV9kc2lfZGV2aWNlDQo+ICpkZXYpDQo+
ICt7DQo+ICsJcmV0dXJuIGRldl9nZXRfZHJ2ZGF0YSgmZGV2LT5kZXYpOw0KPiArfQ0KPiArDQo+
ICtzdGF0aWMgaW5saW5lIHZvaWQgbWlwaV9kc2lfc2V0X2RydmRhdGEoc3RydWN0IG1pcGlfZHNp
X2RldmljZSAqZGV2LA0KPiArCQkJCQl2b2lkICpkYXRhKQ0KPiArew0KPiArCWRldl9zZXRfZHJ2
ZGF0YSgmZGV2LT5kZXYsIGRhdGEpOw0KPiArfQ0KPiArDQo+ICtpbnQgb2ZfbWlwaV9kc2lfcmVn
aXN0ZXJfZGV2aWNlcyhzdHJ1Y3QgbWlwaV9kc2lfYnVzICpidXMpOw0KPiArdm9pZCBtaXBpX2Rz
aV91bnJlZ2lzdGVyX2RldmljZXMoc3RydWN0IG1pcGlfZHNpX2J1cyAqYnVzKTsNCj4gKw0KPiAr
LyogbW9kdWxlX21pcGlfZHNpX2RyaXZlcigpIC0gSGVscGVyIG1hY3JvIGZvciBkcml2ZXJzIHRo
YXQgZG9uJ3QgZG8NCj4gKyAqIGFueXRoaW5nIHNwZWNpYWwgaW4gbW9kdWxlIGluaXQvZXhpdC4g
IFRoaXMgZWxpbWluYXRlcyBhIGxvdCBvZg0KPiArICogYm9pbGVycGxhdGUuICBFYWNoIG1vZHVs
ZSBtYXkgb25seSB1c2UgdGhpcyBtYWNybyBvbmNlLCBhbmQNCj4gKyAqIGNhbGxpbmcgaXQgcmVw
bGFjZXMgbW9kdWxlX2luaXQoKSBhbmQgbW9kdWxlX2V4aXQoKQ0KPiArICovDQo+ICsjZGVmaW5l
IG1vZHVsZV9taXBpX2RzaV9kcml2ZXIoX19taXBpX2RzaV9kcml2ZXIpIFwNCj4gKwltb2R1bGVf
ZHJpdmVyKF9fbWlwaV9kc2lfZHJpdmVyLCBtaXBpX2RzaV9kcml2ZXJfcmVnaXN0ZXIsIFwNCj4g
KwkJCW1pcGlfZHNpX2RyaXZlcl91bnJlZ2lzdGVyKQ0KPiArDQo+ICtpbnQgbWlwaV9kc2lfc2V0
X3Bvd2VyKHN0cnVjdCBtaXBpX2RzaV9kZXZpY2UgKmRldiwgYm9vbCBvbik7DQo+ICtpbnQgbWlw
aV9kc2lfc2V0X3N0cmVhbShzdHJ1Y3QgbWlwaV9kc2lfZGV2aWNlICpkZXYsIGJvb2wgb24pOw0K
PiAraW50IG1pcGlfZHNpX2Rjc193cml0ZShzdHJ1Y3QgbWlwaV9kc2lfZGV2aWNlICpkZXYsIGlu
dCBjaGFubmVsLCBjb25zdCB1OA0KPiAqZGF0YSwNCj4gKwkJICAgICAgIHNpemVfdCBsZW4pOw0K
PiAraW50IG1pcGlfZHNpX2Rjc19yZWFkKHN0cnVjdCBtaXBpX2RzaV9kZXZpY2UgKmRldiwgaW50
IGNoYW5uZWwsIHU4IGNtZCwNCj4gKwkJICAgICAgdTggKmRhdGEsIHNpemVfdCBsZW4pOw0KPiAr
DQo+ICsjZGVmaW5lIG1pcGlfZHNpX2Rjc193cml0ZV9zZXEoZGV2LCBjaGFubmVsLCBzZXEuLi4p
IFwNCj4gKyh7XA0KPiArCWNvbnN0IHU4IGRbXSA9IHsgc2VxIH07XA0KPiArCUJVSUxEX0JVR19P
Tl9NU0coQVJSQVlfU0laRShkKSA+IDY0LCAiRENTIHNlcXVlbmNlIHRvbyBsb25nIGZvcg0KPiBz
dGFjayIpO1wNCj4gKwltaXBpX2RzaV9kY3Nfd3JpdGUoZGV2LCBjaGFubmVsLCBkLCBBUlJBWV9T
SVpFKGQpKTtcDQo+ICt9KQ0KPiArDQo+ICsjZGVmaW5lIG1pcGlfZHNpX2Rjc193cml0ZV9zdGF0
aWNfc2VxKGRldiwgY2hhbm5lbCwgc2VxLi4uKSBcDQo+ICsoe1wNCj4gKwlzdGF0aWMgY29uc3Qg
dTggZFtdID0geyBzZXEgfTtcDQo+ICsJbWlwaV9kc2lfZGNzX3dyaXRlKGRldiwgY2hhbm5lbCwg
ZCwgQVJSQVlfU0laRShkKSk7XA0KPiArfSkNCj4gKw0KPiArI2VuZGlmIC8qIF9fTUlQSV9EU0lf
QlVTX18gKi8NCg0KSSBtYXkgd2VsbCBoYXZlIG1pc3NlZCBzb21ldGhpbmcsIGJ1dCBJIGNhbid0
IHNlZSBleGFjdGx5IGhvdyBhIGNvbW1hbmQgbW9kZQ0KdXBkYXRlIHdvdWxkIGJlIGRvbmUgd2l0
aCB0aGlzIGludGVyZmFjZS4gV291bGQgdGhpcyByZXF1aXJlIHJlcGVhdGVkIGNhbGxzIHRvDQou
dHJhbnNmZXI/IFN1Y2ggdHJhbnNmZXJzIHdvdWxkIG5lZWQgdG8gYmUgZmxhZ2dlZCBhcyByZXF1
aXJpbmcNCnN5bmNocm9uaXNhdGlvbiB3aXRoIGEgdGVhcmluZyBlZmZlY3QgY29udHJvbCBzaWdu
YWwgLSBlaXRoZXIgdGhlIGluYmFuZA0KbWV0aG9kIG9yIGEgZGVkaWNhdGVkIGxpbmUuIEkgc3Vz
cGVjdCBtYW55IGhhcmR3YXJlIGltcGxlbWVudGF0aW9ucyB3aWxsIGhhdmUNCmEgc3BlY2lmaWMg
bWV0aG9kIGZvciB0cmFuc2ZlcnJpbmcgcGl4ZWwgZGF0YSBpbiBhIERTSSBjb21tYW5kIG1vZGUg
dHJhbnNmZXIuDQoNClRoZSBjb21tYW5kIHNlbmRpbmcgcGVyaW9kIGR1cmluZyB2aWRlbyBtb2Rl
IHNob3VsZCBwcm9iYWJseSBiZSBjb25maWd1cmFibGUNCm9uIGEgcGVyLXRyYW5zZmVyIGJhc2lz
LiBTb21lIGNvbW1hbmRzIGhhdmUgdG8gYmUgc3luY2hyb25pc2VkIHdpdGggdmVydGljYWwNCmJs
YW5raW5nLCBvdGhlcnMgZG8gbm90LiBUaGlzIGNvdWxkIHBlcmhhcHMgYmUgY29tYmluZWQgd2l0
aCBhIHdpZGVyDQpjb25maWd1cmF0aW9uIG9wdGlvbiBmb3IgYSBnaXZlbiBwYW5lbCBvciBpbnRl
cmZhY2UuIFNpbWlsYXJseSwgc2VsZWN0aW9uIG9mDQpsb3cgcG93ZXIgKExQKSBhbmQgaGlnaCBz
cGVlZCAoSFMpIG1vZGUgb24gYSBwZXItdHJhbnNmZXIgYmFzaXMgY2FuIGJlIG5lZWRlZA0KZm9y
IHNvbWUgcGFuZWxzLg0KDQpJcyB0aGVyZSBhIG1lY2hhbmlzbSBmb3IgY29udHJvbGxpbmcgdWx0
cmEtbG93IHBvd2VyIHN0YXRlIChVTFBTKSBlbnRyeT8gQWxzbywNCmlzIHRoZXJlIGEgbWV0aG9k
IGZvciBzZW5kaW5nIGFyYml0cmFyeSB0cmlnZ2VyIG1lc3NhZ2VzIChlZyB0aGUgcmVzZXQNCnRy
aWdnZXIpPw0KDQpUaGFua3MsDQoNCkJlcnQuDQotLSANCkJlcnQgS2Vud2FyZA0KU29mdHdhcmUg
RW5naW5lZXINCkJyb2FkY29tIE1vYmlsZSBQbGF0Zm9ybSBTb2x1dGlvbnMNCkNhbWJyaWRnZSwg
VUsNCg=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox