[PATCH 0/2] Drivers: hv: vmbus: make bus ids in sysfs persistent
Bus ids for VMBus devices in /sys/bus/vmbus/devices/ are not guaranteed to be persistent across reboot or kernel restart and this causes problems for some tools. E.g. kexec tools use these ids to identify NIC on kdump. Fix the issue by using relid from channel offer as the unique id instead of an auto incremented counter. Vitaly Kuznetsov (2): Drivers: hv: make VMBus bus ids persistent Drivers: hv: get rid of id in struct vmbus_channel drivers/hv/channel_mgmt.c | 2 -- drivers/hv/vmbus_drv.c| 2 +- include/linux/hyperv.h| 3 --- 3 files changed, 1 insertion(+), 6 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] Drivers: hv: make VMBus bus ids persistent
Some tools use bus ids to identify devices and they count on the fact that these ids are persistent across reboot. This may be not true for VMBus as we use auto incremented counter from alloc_channel() as such id. Switch to using child_relid from channel offer, this id is supposed to be persistent. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/vmbus_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index e82f7e1..ef42909 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -962,7 +962,7 @@ int vmbus_device_register(struct hv_device *child_device_obj) int ret = 0; dev_set_name(&child_device_obj->device, "vmbus_%d", -child_device_obj->channel->id); +child_device_obj->channel->offermsg.child_relid); child_device_obj->device.bus = &hv_bus; child_device_obj->device.parent = &hv_acpi_dev->dev; -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] Drivers: hv: get rid of id in struct vmbus_channel
The auto incremented counter is not being used anymore, get rid of it.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/channel_mgmt.c | 2 --
include/linux/hyperv.h| 3 ---
2 files changed, 5 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index b6c1211..4b4a41d 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -251,14 +251,12 @@ EXPORT_SYMBOL_GPL(vmbus_prep_negotiate_resp);
*/
static struct vmbus_channel *alloc_channel(void)
{
- static atomic_t chan_num = ATOMIC_INIT(0);
struct vmbus_channel *channel;
channel = kzalloc(sizeof(*channel), GFP_ATOMIC);
if (!channel)
return NULL;
- channel->id = atomic_inc_return(&chan_num);
channel->acquire_ring_lock = true;
spin_lock_init(&channel->inbound_lock);
spin_lock_init(&channel->lock);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index b10954a..d9371a7 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -701,9 +701,6 @@ struct vmbus_device {
};
struct vmbus_channel {
- /* Unique channel id */
- int id;
-
struct list_head listentry;
struct hv_device *device_obj;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/7] staging/android: display sync_pt name on debugfs
Op 08-08-16 om 21:59 schreef Gustavo Padovan:
> 2016-08-08 Maarten Lankhorst :
>
>> Op 20-06-16 om 17:53 schreef Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> When creating a sync_pt the name received wasn't used anywhere.
>>> Now we add it to the sync info debug output to make it easier to indetify
>>> the userspace name of that sync pt.
>>>
>>> Signed-off-by: Gustavo Padovan
>>> ---
>>> drivers/staging/android/sw_sync.c| 16
>>> drivers/staging/android/sync_debug.c | 5 +++--
>>> drivers/staging/android/sync_debug.h | 9 +
>>> 3 files changed, 16 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/staging/android/sw_sync.c
>>> b/drivers/staging/android/sw_sync.c
>>> index b4ae092..ea27512 100644
>>> --- a/drivers/staging/android/sw_sync.c
>>> +++ b/drivers/staging/android/sw_sync.c
>>> @@ -37,15 +37,6 @@ struct sw_sync_create_fence_data {
>>> struct sw_sync_create_fence_data)
>>> #define SW_SYNC_IOC_INC_IOW(SW_SYNC_IOC_MAGIC, 1,
>>> __u32)
>>>
>>> -static const struct fence_ops timeline_fence_ops;
>>> -
>>> -static inline struct sync_pt *fence_to_sync_pt(struct fence *fence)
>>> -{
>>> - if (fence->ops != &timeline_fence_ops)
>>> - return NULL;
>>> - return container_of(fence, struct sync_pt, base);
>>> -}
>>> -
>>> struct sync_timeline *sync_timeline_create(const char *name)
>>> {
>>> struct sync_timeline *obj;
>>> @@ -108,7 +99,7 @@ static void sync_timeline_signal(struct sync_timeline
>>> *obj, unsigned int inc)
>>> }
>>>
>>> static struct sync_pt *sync_pt_create(struct sync_timeline *obj, int size,
>>> -unsigned int value)
>>> +unsigned int value, char *name)
>>> {
>>> unsigned long flags;
>>> struct sync_pt *pt;
>>> @@ -120,6 +111,7 @@ static struct sync_pt *sync_pt_create(struct
>>> sync_timeline *obj, int size,
>>> if (!pt)
>>> return NULL;
>>>
>>> + strlcpy(pt->name, name, sizeof(pt->name));
>>> spin_lock_irqsave(&obj->child_list_lock, flags);
>>> sync_timeline_get(obj);
>>> fence_init(&pt->base, &timeline_fence_ops, &obj->child_list_lock,
>>> @@ -191,7 +183,7 @@ static void timeline_fence_timeline_value_str(struct
>>> fence *fence,
>>> snprintf(str, size, "%d", parent->value);
>>> }
>>>
>>> -static const struct fence_ops timeline_fence_ops = {
>>> +const struct fence_ops timeline_fence_ops = {
>>> .get_driver_name = timeline_fence_get_driver_name,
>>> .get_timeline_name = timeline_fence_get_timeline_name,
>>> .enable_signaling = timeline_fence_enable_signaling,
>>> @@ -252,7 +244,7 @@ static long sw_sync_ioctl_create_fence(struct
>>> sync_timeline *obj,
>>> goto err;
>>> }
>>>
>>> - pt = sync_pt_create(obj, sizeof(*pt), data.value);
>>> + pt = sync_pt_create(obj, sizeof(*pt), data.value, data.name);
>>> if (!pt) {
>>> err = -ENOMEM;
>>> goto err;
>>> diff --git a/drivers/staging/android/sync_debug.c
>>> b/drivers/staging/android/sync_debug.c
>>> index 4c5a855..b732ea3 100644
>>> --- a/drivers/staging/android/sync_debug.c
>>> +++ b/drivers/staging/android/sync_debug.c
>>> @@ -75,13 +75,14 @@ static void sync_print_fence(struct seq_file *s, struct
>>> fence *fence, bool show)
>>> {
>>> int status = 1;
>>> struct sync_timeline *parent = fence_parent(fence);
>>> + struct sync_pt *pt = fence_to_sync_pt(fence);
>>>
>>> if (fence_is_signaled_locked(fence))
>>> status = fence->status;
>>>
>>> - seq_printf(s, " %s%sfence %s",
>>> + seq_printf(s, " %s%sfence %s %s",
>>>show ? parent->name : "",
>>> - show ? "_" : "",
>>> + show ? "_" : "", pt->name,
>>>sync_status_str(status));
>>>
>> NAK,
>> A fence in sync_print_fence can be of any type. If you want to print the
>> name, use the fence_value_str callback.
> Indeed. But fence_value_str doesn't return the sync_pt name, but the
> seqno of that fence. I'll keep this change out for the de-staging and
> then try to come with something that works better.
>
> Gustavo
This will probably cause a kernel panic if you keep it like it is and you look
at
debugfs for non sync_pt fences, it should definitely be fixed before destaging.
Ignoring sync_pt name would be better than crashing.
~Maarten
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/7] staging/android: display sync_pt name on debugfs
2016-08-09 Maarten Lankhorst :
> Op 08-08-16 om 21:59 schreef Gustavo Padovan:
> > 2016-08-08 Maarten Lankhorst :
> >
> >> Op 20-06-16 om 17:53 schreef Gustavo Padovan:
> >>> From: Gustavo Padovan
> >>>
> >>> When creating a sync_pt the name received wasn't used anywhere.
> >>> Now we add it to the sync info debug output to make it easier to indetify
> >>> the userspace name of that sync pt.
> >>>
> >>> Signed-off-by: Gustavo Padovan
> >>> ---
> >>> drivers/staging/android/sw_sync.c| 16
> >>> drivers/staging/android/sync_debug.c | 5 +++--
> >>> drivers/staging/android/sync_debug.h | 9 +
> >>> 3 files changed, 16 insertions(+), 14 deletions(-)
> >>>
> >>> diff --git a/drivers/staging/android/sw_sync.c
> >>> b/drivers/staging/android/sw_sync.c
> >>> index b4ae092..ea27512 100644
> >>> --- a/drivers/staging/android/sw_sync.c
> >>> +++ b/drivers/staging/android/sw_sync.c
> >>> @@ -37,15 +37,6 @@ struct sw_sync_create_fence_data {
> >>> struct sw_sync_create_fence_data)
> >>> #define SW_SYNC_IOC_INC _IOW(SW_SYNC_IOC_MAGIC, 1,
> >>> __u32)
> >>>
> >>> -static const struct fence_ops timeline_fence_ops;
> >>> -
> >>> -static inline struct sync_pt *fence_to_sync_pt(struct fence *fence)
> >>> -{
> >>> - if (fence->ops != &timeline_fence_ops)
> >>> - return NULL;
> >>> - return container_of(fence, struct sync_pt, base);
> >>> -}
> >>> -
> >>> struct sync_timeline *sync_timeline_create(const char *name)
> >>> {
> >>> struct sync_timeline *obj;
> >>> @@ -108,7 +99,7 @@ static void sync_timeline_signal(struct sync_timeline
> >>> *obj, unsigned int inc)
> >>> }
> >>>
> >>> static struct sync_pt *sync_pt_create(struct sync_timeline *obj, int
> >>> size,
> >>> - unsigned int value)
> >>> + unsigned int value, char *name)
> >>> {
> >>> unsigned long flags;
> >>> struct sync_pt *pt;
> >>> @@ -120,6 +111,7 @@ static struct sync_pt *sync_pt_create(struct
> >>> sync_timeline *obj, int size,
> >>> if (!pt)
> >>> return NULL;
> >>>
> >>> + strlcpy(pt->name, name, sizeof(pt->name));
> >>> spin_lock_irqsave(&obj->child_list_lock, flags);
> >>> sync_timeline_get(obj);
> >>> fence_init(&pt->base, &timeline_fence_ops, &obj->child_list_lock,
> >>> @@ -191,7 +183,7 @@ static void timeline_fence_timeline_value_str(struct
> >>> fence *fence,
> >>> snprintf(str, size, "%d", parent->value);
> >>> }
> >>>
> >>> -static const struct fence_ops timeline_fence_ops = {
> >>> +const struct fence_ops timeline_fence_ops = {
> >>> .get_driver_name = timeline_fence_get_driver_name,
> >>> .get_timeline_name = timeline_fence_get_timeline_name,
> >>> .enable_signaling = timeline_fence_enable_signaling,
> >>> @@ -252,7 +244,7 @@ static long sw_sync_ioctl_create_fence(struct
> >>> sync_timeline *obj,
> >>> goto err;
> >>> }
> >>>
> >>> - pt = sync_pt_create(obj, sizeof(*pt), data.value);
> >>> + pt = sync_pt_create(obj, sizeof(*pt), data.value, data.name);
> >>> if (!pt) {
> >>> err = -ENOMEM;
> >>> goto err;
> >>> diff --git a/drivers/staging/android/sync_debug.c
> >>> b/drivers/staging/android/sync_debug.c
> >>> index 4c5a855..b732ea3 100644
> >>> --- a/drivers/staging/android/sync_debug.c
> >>> +++ b/drivers/staging/android/sync_debug.c
> >>> @@ -75,13 +75,14 @@ static void sync_print_fence(struct seq_file *s,
> >>> struct fence *fence, bool show)
> >>> {
> >>> int status = 1;
> >>> struct sync_timeline *parent = fence_parent(fence);
> >>> + struct sync_pt *pt = fence_to_sync_pt(fence);
> >>>
> >>> if (fence_is_signaled_locked(fence))
> >>> status = fence->status;
> >>>
> >>> - seq_printf(s, " %s%sfence %s",
> >>> + seq_printf(s, " %s%sfence %s %s",
> >>> show ? parent->name : "",
> >>> -show ? "_" : "",
> >>> +show ? "_" : "", pt->name,
> >>> sync_status_str(status));
> >>>
> >> NAK,
> >> A fence in sync_print_fence can be of any type. If you want to print the
> >> name, use the fence_value_str callback.
> > Indeed. But fence_value_str doesn't return the sync_pt name, but the
> > seqno of that fence. I'll keep this change out for the de-staging and
> > then try to come with something that works better.
> >
> > Gustavo
>
> This will probably cause a kernel panic if you keep it like it is and you
> look at
> debugfs for non sync_pt fences, it should definitely be fixed before
> destaging.
> Ignoring sync_pt name would be better than crashing.
No, I meant ignoring sync_pt name for now. I've already sent v2 without
it.
Gustavo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE
On 08/08/2016 10:49 AM, Laura Abbott wrote: > arm may need the kernel_force_cache APIs to guarantee data consistency. > Implement versions of these APIs based on the DMA APIs. > > Signed-off-by: Laura Abbott > --- > arch/arm/include/asm/cacheflush.h | 4 ++ > arch/arm/mm/dma-mapping.c | 119 > -- > arch/arm/mm/flush.c | 115 Why is the code moved between dma-mapping.c and flush.c? It was not obvious while looking at these patches why this is needed. -- Florian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/rtl8188eu/core/rtw_cmd: Fixes semaphore locking
The code did not lock the &pcmdpriv->terminate_cmdthread_sema before using it.
The code had an up() where a down() should've been. This patch fixes that.
Signed-off-by: Lidza Louina
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 7748523..16f0b19 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -162,7 +162,7 @@ int rtw_cmd_thread(void *context)
allow_signal(SIGTERM);
pcmdpriv->cmdthd_running = true;
- up(&pcmdpriv->terminate_cmdthread_sema);
+ down(&pcmdpriv->terminate_cmdthread_sema);
RT_TRACE(_module_rtl871x_cmd_c_, _drv_info_, ("start r871x
rtw_cmd_thread \n"));
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE
On 08/09/2016 02:56 PM, Florian Fainelli wrote: On 08/08/2016 10:49 AM, Laura Abbott wrote: arm may need the kernel_force_cache APIs to guarantee data consistency. Implement versions of these APIs based on the DMA APIs. Signed-off-by: Laura Abbott --- arch/arm/include/asm/cacheflush.h | 4 ++ arch/arm/mm/dma-mapping.c | 119 -- arch/arm/mm/flush.c | 115 Why is the code moved between dma-mapping.c and flush.c? It was not obvious while looking at these patches why this is needed. I wanted to use the cache flushing routines from dma-mapping.c and it seemed better to pull them out vs. trying to put more generic cache flushing code in dma-mapping.c. flush.c seemed like an appropriate place although I forgot about the dependency on CONFIG_MMU. It can certainly remain in dma-mapping.c if deemed appropriate. Thanks, Laura ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE
On 08/09/2016 05:13 PM, Laura Abbott wrote: > On 08/09/2016 02:56 PM, Florian Fainelli wrote: >> On 08/08/2016 10:49 AM, Laura Abbott wrote: >>> arm may need the kernel_force_cache APIs to guarantee data consistency. >>> Implement versions of these APIs based on the DMA APIs. >>> >>> Signed-off-by: Laura Abbott >>> --- >>> arch/arm/include/asm/cacheflush.h | 4 ++ >>> arch/arm/mm/dma-mapping.c | 119 >>> -- >>> arch/arm/mm/flush.c | 115 >>> >> >> Why is the code moved between dma-mapping.c and flush.c? It was not >> obvious while looking at these patches why this is needed. >> > > I wanted to use the cache flushing routines from dma-mapping.c and > it seemed better to pull them out vs. trying to put more generic > cache flushing code in dma-mapping.c. flush.c seemed like an > appropriate place although I forgot about the dependency on CONFIG_MMU. > It can certainly remain in dma-mapping.c if deemed appropriate. My concern is that this is an area of the kernel where you might be looking for stable backports, so avoiding churn in there is desireable and if the new cache APIs become accepted and standard, since they are building directly on top of the DMA-API, keeping them in dma-mapping.c seems consistent. My 2 cents. -- Florian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
