[PATCH] Staging: bcm: PHSModule.c: Matching the function definition with function declaration
From: Shalin Mehta
The function implementations of the PHSModule didn't match with the
declaration. The functions are static
in the declaration but in the implemntation they are non-static
Signed-off-by: Shalin Mehta
---
drivers/staging/bcm/PHSModule.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/bcm/PHSModule.c b/drivers/staging/bcm/PHSModule.c
index af5d22f..56c5bee 100644
--- a/drivers/staging/bcm/PHSModule.c
+++ b/drivers/staging/bcm/PHSModule.c
@@ -596,7 +596,7 @@ ULONG PhsDeleteSFRules(IN void *pvContext, IN B_UINT16
uiVcid)
* 0 if successful,
* >0 Error.
*/
-ULONG PhsCompress(IN void *pvContext,
+static ULONG PhsCompress(IN void *pvContext,
IN B_UINT16 uiVcid,
IN B_UINT16 uiClsId,
IN void *pvInputBuffer,
@@ -677,7 +677,7 @@ ULONG PhsCompress(IN void *pvContext,
* 0 if successful,
* >0 Error.
*/
-ULONG PhsDeCompress(IN void *pvContext,
+static ULONG PhsDeCompress(IN void *pvContext,
IN B_UINT16 uiVcid,
IN void *pvInputBuffer,
OUT void *pvOutputBuffer,
@@ -829,7 +829,7 @@ UINT GetServiceFlowEntry(IN struct bcm_phs_table
*psServiceFlowTable,
return PHS_INVALID_TABLE_INDEX;
}
-UINT GetClassifierEntry(IN struct bcm_phs_classifier_table *pstClassifierTable,
+static UINT GetClassifierEntry(IN struct bcm_phs_classifier_table
*pstClassifierTable,
IN B_UINT32 uiClsid, enum bcm_phs_classifier_context
eClsContext,
OUT struct bcm_phs_classifier_entry
**ppstClassifierEntry)
{
@@ -880,7 +880,7 @@ static UINT GetPhsRuleEntry(IN struct
bcm_phs_classifier_table *pstClassifierTab
return PHS_INVALID_TABLE_INDEX;
}
-UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16 uiClsId,
+static UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16
uiClsId,
IN struct bcm_phs_table *psServiceFlowTable,
struct bcm_phs_rule *psPhsRule,
B_UINT8 u8AssociatedPHSI)
@@ -913,7 +913,7 @@ UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN
B_UINT16 uiClsId,
return uiStatus;
}
-UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
+static UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
IN B_UINT16 uiClsId,
IN struct bcm_phs_entry *pstServiceFlowEntry,
struct bcm_phs_rule *psPhsRule,
@@ -1239,7 +1239,7 @@ void DumpPhsRules(struct bcm_phs_extension
*pDeviceExtension)
* header.
* 0 -If PHS rule is NULL.If PHSI is 0 indicateing packet as
uncompressed.
*/
-int phs_decompress(unsigned char *in_buf,
+static int phs_decompress(unsigned char *in_buf,
unsigned char *out_buf,
struct bcm_phs_rule *decomp_phs_rules,
UINT *header_size)
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: bcm: PHSModule.c: Matching the function definition with function declaration
From: Shalin Mehta
NOTE: Sending it again. I got mail delivery failure due to typo in emai ID
gre...@linuxfoundation.org
The function implementations of the PHSModule didn't match with the
declaration. The functions are static
in the declaration but in the implemntation they are non-static
Signed-off-by: Shalin Mehta
---
drivers/staging/bcm/PHSModule.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/bcm/PHSModule.c b/drivers/staging/bcm/PHSModule.c
index af5d22f..56c5bee 100644
--- a/drivers/staging/bcm/PHSModule.c
+++ b/drivers/staging/bcm/PHSModule.c
@@ -596,7 +596,7 @@ ULONG PhsDeleteSFRules(IN void *pvContext, IN B_UINT16
uiVcid)
* 0 if successful,
* >0 Error.
*/
-ULONG PhsCompress(IN void *pvContext,
+static ULONG PhsCompress(IN void *pvContext,
IN B_UINT16 uiVcid,
IN B_UINT16 uiClsId,
IN void *pvInputBuffer,
@@ -677,7 +677,7 @@ ULONG PhsCompress(IN void *pvContext,
* 0 if successful,
* >0 Error.
*/
-ULONG PhsDeCompress(IN void *pvContext,
+static ULONG PhsDeCompress(IN void *pvContext,
IN B_UINT16 uiVcid,
IN void *pvInputBuffer,
OUT void *pvOutputBuffer,
@@ -829,7 +829,7 @@ UINT GetServiceFlowEntry(IN struct bcm_phs_table
*psServiceFlowTable,
return PHS_INVALID_TABLE_INDEX;
}
-UINT GetClassifierEntry(IN struct bcm_phs_classifier_table *pstClassifierTable,
+static UINT GetClassifierEntry(IN struct bcm_phs_classifier_table
*pstClassifierTable,
IN B_UINT32 uiClsid, enum bcm_phs_classifier_context
eClsContext,
OUT struct bcm_phs_classifier_entry
**ppstClassifierEntry)
{
@@ -880,7 +880,7 @@ static UINT GetPhsRuleEntry(IN struct
bcm_phs_classifier_table *pstClassifierTab
return PHS_INVALID_TABLE_INDEX;
}
-UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16 uiClsId,
+static UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16
uiClsId,
IN struct bcm_phs_table *psServiceFlowTable,
struct bcm_phs_rule *psPhsRule,
B_UINT8 u8AssociatedPHSI)
@@ -913,7 +913,7 @@ UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN
B_UINT16 uiClsId,
return uiStatus;
}
-UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
+static UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
IN B_UINT16 uiClsId,
IN struct bcm_phs_entry *pstServiceFlowEntry,
struct bcm_phs_rule *psPhsRule,
@@ -1239,7 +1239,7 @@ void DumpPhsRules(struct bcm_phs_extension
*pDeviceExtension)
* header.
* 0 -If PHS rule is NULL.If PHSI is 0 indicateing packet as
uncompressed.
*/
-int phs_decompress(unsigned char *in_buf,
+static int phs_decompress(unsigned char *in_buf,
unsigned char *out_buf,
struct bcm_phs_rule *decomp_phs_rules,
UINT *header_size)
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/6] Staging/iio/adc/touchscreen/MXS: add interrupt driven touch detection
Hi Dmitry, On Monday 16 September 2013 17:28:46 Dmitry Torokhov wrote: > [...] > > > static int mxs_lradc_ts_register(struct mxs_lradc *lradc) > > > @@ -641,6 +1056,7 @@ static void mxs_lradc_ts_unregister(struct > > > mxs_lradc *lradc) > > > > > > cancel_work_sync(&lradc->ts_work); > > > > > > + mxs_lradc_disable_ts(lradc); > > > input_unregister_device(lradc->ts_input); > > > } > > This looks iffy... Normally you disable the device so that it does not > generate more interrupts, and then cancel outstanding work(s), otherwise > newly generated interrupts may cause more work to be scheduled. Or I > missed some of the context and this is not a concern here? This part gets removed in patch 6/6: @@ -1054,8 +891,6 @@ static void mxs_lradc_ts_unregister(struct mxs_lradc *lradc) if (!lradc->use_touchscreen) return; - cancel_work_sync(&lradc->ts_work); - mxs_lradc_disable_ts(lradc); input_unregister_device(lradc->ts_input); } But you are right, I should move this into patch 5/6. Thanks Regards, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ | ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: bcm: PHSModule.c: Matching the function definition with function declaration
On Tue, Sep 17, 2013 at 12:12:42AM -0700, Shalin Mehta wrote: > From: Shalin Mehta > > NOTE: Sending it again. I got mail delivery failure due to typo in emai ID > gre...@linuxfoundation.org > Put these comments that don't belong in the changelog under the --- cut off line with the diffstat. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: bcm: PHSModule.c: Matching the function definition with function declaration
On Tue, 17 Sep 2013, Shalin Mehta wrote:
> From: Shalin Mehta
>
> NOTE: Sending it again. I got mail delivery failure due to typo in emai ID
> gre...@linuxfoundation.org
I think that such a comment should go below the ---, since it doesn't have
to be preserved in git.
julia
>
>
> The function implementations of the PHSModule didn't match with the
> declaration. The functions are static
> in the declaration but in the implemntation they are non-static
>
> Signed-off-by: Shalin Mehta
> ---
> drivers/staging/bcm/PHSModule.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/bcm/PHSModule.c b/drivers/staging/bcm/PHSModule.c
> index af5d22f..56c5bee 100644
> --- a/drivers/staging/bcm/PHSModule.c
> +++ b/drivers/staging/bcm/PHSModule.c
> @@ -596,7 +596,7 @@ ULONG PhsDeleteSFRules(IN void *pvContext, IN B_UINT16
> uiVcid)
> * 0 if successful,
> * >0 Error.
> */
> -ULONG PhsCompress(IN void *pvContext,
> +static ULONG PhsCompress(IN void *pvContext,
> IN B_UINT16 uiVcid,
> IN B_UINT16 uiClsId,
> IN void *pvInputBuffer,
> @@ -677,7 +677,7 @@ ULONG PhsCompress(IN void *pvContext,
> * 0 if successful,
> * >0 Error.
> */
> -ULONG PhsDeCompress(IN void *pvContext,
> +static ULONG PhsDeCompress(IN void *pvContext,
> IN B_UINT16 uiVcid,
> IN void *pvInputBuffer,
> OUT void *pvOutputBuffer,
> @@ -829,7 +829,7 @@ UINT GetServiceFlowEntry(IN struct bcm_phs_table
> *psServiceFlowTable,
> return PHS_INVALID_TABLE_INDEX;
> }
>
> -UINT GetClassifierEntry(IN struct bcm_phs_classifier_table
> *pstClassifierTable,
> +static UINT GetClassifierEntry(IN struct bcm_phs_classifier_table
> *pstClassifierTable,
> IN B_UINT32 uiClsid, enum bcm_phs_classifier_context
> eClsContext,
> OUT struct bcm_phs_classifier_entry
> **ppstClassifierEntry)
> {
> @@ -880,7 +880,7 @@ static UINT GetPhsRuleEntry(IN struct
> bcm_phs_classifier_table *pstClassifierTab
> return PHS_INVALID_TABLE_INDEX;
> }
>
> -UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16
> uiClsId,
> +static UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16
> uiClsId,
> IN struct bcm_phs_table *psServiceFlowTable,
> struct bcm_phs_rule *psPhsRule,
> B_UINT8 u8AssociatedPHSI)
> @@ -913,7 +913,7 @@ UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid,
> IN B_UINT16 uiClsId,
> return uiStatus;
> }
>
> -UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
> +static UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
> IN B_UINT16 uiClsId,
> IN struct bcm_phs_entry *pstServiceFlowEntry,
> struct bcm_phs_rule *psPhsRule,
> @@ -1239,7 +1239,7 @@ void DumpPhsRules(struct bcm_phs_extension
> *pDeviceExtension)
> * header.
> * 0 -If PHS rule is NULL.If PHSI is 0 indicateing packet as
> uncompressed.
> */
> -int phs_decompress(unsigned char *in_buf,
> +static int phs_decompress(unsigned char *in_buf,
> unsigned char *out_buf,
> struct bcm_phs_rule *decomp_phs_rules,
> UINT *header_size)
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 15/24] Staging: winbond: reg: seventh of the patches that fixes lines over 80 characters
On Tue, Sep 17, 2013 at 02:29:22PM +0530, Adil Mujeeb wrote: > Hi, > > > >- PowerData = (1 << 31) | (0 << 30) | (24 << 24) | > BitReverse(w89rf242_txvga_data[i][0], 24); > >+ PowerData = (1 << 31) | (0 << 30) | (24 << 24) > >+ | BitReverse(w89rf242_txvga_data[i][0], 24); > . > . > > >- reg->M38_MacControl = (DEFAULT_RATE_RETRY_LIMIT << 8) | > (DEFAULT_LONG_RETRY_LIMIT << 4) | DEFAULT_SHORT_RETRY_LIMIT; > >+ reg->M38_MacControl = (DEFAULT_RATE_RETRY_LIMIT << 8) | > >+ (DEFAULT_LONG_RETRY_LIMIT << 4) | > >+ DEFAULT_SHORT_RETRY_LIMIT; > > I think consistency is needed. Either break the lines putting the OR > operator ( | ) at the start of new line or at the end of each line. People > has its own preference but here you have used both style in single file. > Just a suggestion. > Put the '|' character at the end of the line. That's the New Unwritten Style Guidelines. Most of the kernel does it this way and it's easier to read. But this could be fixed in a later patch instead of redoing the whole series. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: rts5139: Use correct USB transfer interval to fix syslog spamming
On 06/03/2013 08:14 PM, Marcus Overhagen wrote: Using correct transfer interval as specified by the USB endpoint when doing the interrupt transfer fixes the warning printed by xhci USB core on every transfer that resulted in spamming "xhci_queue_intr_tx: 74 callbacks suppressed" to syslog every 5 seconds. Signed-off-by: Marcus Overhagen --- drivers/staging/rts5139/rts51x_transport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rts5139/rts51x_transport.c b/drivers/staging/rts5139/rts51x_transport.c index c573618..c172f4a 100644 --- a/drivers/staging/rts5139/rts51x_transport.c +++ b/drivers/staging/rts5139/rts51x_transport.c @@ -635,10 +635,10 @@ int rts51x_get_epc_status(struct rts51x_chip *chip, u16 *status) ep = chip->usb->pusb_dev->ep_in[usb_pipeendpoint(pipe)]; /* fill and submit the URB */ - /* We set interval to 1 here, so the polling interval is controlled -* by our polling thread */ + /* Set interval to 10 here to match the endpoint descriptor, +* the polling interval is controlled by the polling thread */ usb_fill_int_urb(chip->usb->intr_urb, chip->usb->pusb_dev, pipe, -status, 2, urb_done_completion, &urb_done, 1); +status, 2, urb_done_completion, &urb_done, 10); result = rts51x_msg_common(chip, chip->usb->intr_urb, 100); This change breaks the rts5139 driver for me: I have been using the rts5139 driver with the built-in card reader of an Asus UX32VD (see http://www.linlap.com/asus_ux32vd for all Details on that hardware) and linux-3.8.8 successfully for quite a long time. I recently upgraded to linux-3.11.1, which includes the above patch. After upgrading I got I/O-errors like the following ones while reading - when I just "dd" from the device to /dev/null, these errors occur after transferring somewhere from ~700MB to ~7GB, and even though this sounds like an erratic behaviour, it is perfectly reproducable every time I just read continously from the device: kernel: [ 1540.909901] sd 8:0:0:0: [sdc] Device not ready kernel: [ 1540.909905] sd 8:0:0:0: [sdc] kernel: [ 1540.909906] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE kernel: [ 1540.909908] sd 8:0:0:0: [sdc] kernel: [ 1540.909909] Sense Key : Not Ready [current] kernel: [ 1540.909912] sd 8:0:0:0: [sdc] kernel: [ 1540.909915] Add. Sense: Medium not present kernel: [ 1540.909917] sd 8:0:0:0: [sdc] CDB: kernel: [ 1540.909918] Read(10): 28 00 00 0f 8d f0 00 00 10 00 kernel: [ 1540.909923] end_request: I/O error, dev sdc, sector 1019376 kernel: [ 1540.909926] quiet_error: 26 callbacks suppressed kernel: [ 1540.909927] Buffer I/O error on device sdc, logical block 127422 kernel: [ 1540.909931] Buffer I/O error on device sdc, logical block 127423 kernel: [ 1540.909961] sd 8:0:0:0: [sdc] Device not ready kernel: [ 1540.909963] sd 8:0:0:0: [sdc] kernel: [ 1540.909963] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE kernel: [ 1540.909965] sd 8:0:0:0: [sdc] kernel: [ 1540.909965] Sense Key : Not Ready [current] kernel: [ 1540.909967] sd 8:0:0:0: [sdc] kernel: [ 1540.909968] Add. Sense: Medium not present kernel: [ 1540.909970] sd 8:0:0:0: [sdc] CDB: kernel: [ 1540.909970] Read(10): 28 00 00 0f 8e 00 00 00 f0 00 kernel: [ 1540.909975] end_request: I/O error, dev sdc, sector 1019392 kernel: [ 1540.909976] Buffer I/O error on device sdc, logical block 127424 kernel: [ 1540.909977] Buffer I/O error on device sdc, logical block 127425 kernel: [ 1540.909978] Buffer I/O error on device sdc, logical block 127426 kernel: [ 1540.909980] Buffer I/O error on device sdc, logical block 127427 kernel: [ 1540.909981] Buffer I/O error on device sdc, logical block 127428 kernel: [ 1540.909982] Buffer I/O error on device sdc, logical block 127429 kernel: [ 1540.909983] Buffer I/O error on device sdc, logical block 127430 kernel: [ 1540.909985] Buffer I/O error on device sdc, logical block 127431 I verified, with different SDXC cards, that I reliably do not get these errors when booting linux-3.8.8, then I reverted status, 2, urb_done_completion, &urb_done, 10); back into status, 2, urb_done_completion, &urb_done, 1); in the linux-3.11.1 source, and verified that then linux-3.11.1 works as good as linux-3.8.8 with the "dd to /dev/null" again, no more I/O-errors like the above. (BTW: The SDXC card I was using most was a SanDisk Extreme Pro 64GB SDXC.) Your comment on the change says it is meant to get rid of syslog messages like: "xhci_queue_intr_tx: 74 callbacks suppressed" I do not have such messages, neither with or without the above change. Regards, Lutz Vieweg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: Add dm-writeboost
Mike, First, thank you for your commenting. I was looking forward to your comments. I suppose you are sensing some "smell" in my design. You are worrying that dm-writeboost will not only confuse users but also fall into worst situation of giving up backward-compatibility after merging into tree. That dm-writeboost's design is too eccentric as a DM target makes you so. That you said > determines whether a device needs formatting, etc. Otherwise I cannot > see how you can properly stack DM devices on writeboost devices > (suspend+resume become tediously different) is a proof of smell. Alasdair also said > I read a statement like that as an indication of an interface or > architectural problem. The device-mapper approach is to 'design out' > problems, rather than relying on users not doing bad things. > Study the existing interfaces used by other targets to understand > some approaches that proved successful, then decide which ones > come closest to your needs. and Mikulas said > Another idea: > > Make the interface of dm-lc (the arguments to constructor, messages and > the status line) the same as dm-cache, so that they can be driven by the > same userspace code. Though I guess this is going too far since dm-writeboost and dm-cache are the different things designing them similar definitely makes sense. are also sensing of smell. I am afraid so I am and I am thinking of re-designing dm-writeboost at the fundamental architectural level. The interfaces will be similar to that of dm-cache as a result. This will be a really a BIG change. > Probably best for you to publish the dm-writeboost code a git repo on > github.com or the like. I just don't see what benefit there is to > putting code like this in staging. Users already need considerable > userspace tools and infrastructure will also be changing in the > near-term (e.g. the migration daemon). Yes, I agree with that regarding the current implementation. I withdraw from the proposal for staging. I am really sorry for Greg and others caring about dm-writeboost. But I will be back after re-designing. staging means lot to get 3rd party users is for sure. Since this will be a big change. I want to agree on the design before going forward. I will explain why the interfaces of dm-writeboost are designed so complicated. Essentially, it is because dm-writeboost supports "cache-sharing". The functionality of sharing a cache by devices is required in some cases. If I remove the functionality the design will be much simpler and the code will be slightly faster. What to be removed after re-designing follows and they are also explaining why cache-sharing makes the design bad. (1) writeboost-mgr (maybe) Mike said > - really dislike the use of an intermediate "writeboost-mgr" target to > administer the writeboost devices. There is no need for this. but I don't think having a singleton intermediate writeboost-mgr is completely weird. dm-thin target also has a singleton thin-pool target that create and destroy thin devices. Below is a description from Documentation/device-mapper/thin-provisioning.txt Using an existing pool device - dmsetup create pool \ --table "0 20971520 thin-pool $metadata_dev $data_dev \ $data_block_size $low_water_mark" i) Creating a new thinly-provisioned volume. To create a new thinly- provisioned volume you must send a message to an active pool device, /dev/mapper/pool in this example. dmsetup message /dev/mapper/pool 0 "create_thin 0" Here '0' is an identifier for the volume, a 24-bit number. It's up to the caller to allocate and manage these identifiers. If the identifier is already in use, the message will fail with -EEXIST. But I do agree on having writeboost-mgr is a smell of over-engineering. A target does nothing at all but being an admin looks little bit weird for a design of DM target. Maybe this should be removed. (2) device_id and cache_id To manage which backing devices are attached to a cache These IDs are needed like dm-thin. But they are not needed if I give up cache-sharing and > - the various typedefs aren't needed (e.g. device_id, cache_id, > cache_nr) will be all cleared. (3) sysfs > device it will establish a proper hierarchy (see: dm_get_device). What > advantages are you seeing from having/managing this sysfs tree? One of the advantages is that userland tools can see the relations between devices. Some GUI application might want to draw that by refering the sysfs. If I get rid of the cache-sharing, the dimension of relations between devices will not be needed and will be removed toward userland and the alternative is to set/get the tunable parameters are thru message and status like dm-cache. In addition, there actually is a smelling code causing by this design. The code below add/remove the sysfs interfaces that should be done in .ctr but is separated for actually very compl
Re: staging: Add dm-writeboost
Hi, Mike There are two designs in my mind regarding the formatting cache. You said > administer the writeboost devices. There is no need for this. Just > have a normal DM target whose .ctr takes care of validation and > determines whether a device needs formatting, etc. makes me wonder how I format the cache device. There are two choices for formatting cache and create a writeboost device standing on the point of removing writeboost-mgr existing in the current design. I will explain them from how the interface will look like. (1) dmsetup create myDevice ... "... $backing_path $cache_path" which will returns error if the superblock of the given cache device is invalid and needs formatting. And then the user formats the cache device by some userland tool. (2) dmsetup create myDevice ... "... $backing_path $cache_path $do_format" which also returns error if the superblock of the given cache device is invalid and needs formatting when $do_format is 0. And then user formats the cache device by setting $do_format to 1 and try again. There pros and cons about the design tradeoffs: - (i) (1) is simpler. do_format parameter in (2) doesn't seem to be sane. (1) is like the interfaces of filesystems where dmsetup create is like mounting a filesystem. - (ii) (2) can implement everything in kernel. It can gather all the information about how the superblock in one place, kernel code. Excuse for the current design: - The reason I design writeboost-mgr is almost regarding (ii) above. writeboost-mgr has a message "format_cache_device" and writeboost-format-cache userland command kicks the message to format cache. - writeboost-mgr has also a message "resume_cache" that validates and builds a in-memory structure according to the cache binding to given $cache_id and user later dmsetup create the writeboost device with the $cache_id. However, resuming the cache metadata should be done under .ctr like dm-cache does and should not relate LV to create and cache by external cache_id is what I realized by looking at the code of dm-cache which calls dm_cache_metadata_open() routines under .ctr . I don't know why I should not do this it is nicer to trust DM guys in RedHat on this point. writeboost-mgr is something like smell of over-engineering but is useful for simplifying the design for above reasons. Which do you think better? Akira ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
On Fri, Sep 13, 2013 at 02:28:35PM +, KY Srinivasan wrote: > > > > -Original Message- > > From: Gleb Natapov [mailto:g...@redhat.com] > > Sent: Friday, September 13, 2013 2:55 AM > > To: KY Srinivasan > > Cc: H. Peter Anvin; x...@kernel.org; gre...@linuxfoundation.org; linux- > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de; > > jbeul...@suse.com; b...@alien8.de > > Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency > > from the hypervisor > > > > On Fri, Sep 13, 2013 at 01:43:09AM +, KY Srinivasan wrote: > > > > > > > > > > -Original Message- > > > > From: H. Peter Anvin [mailto:h...@zytor.com] > > > > Sent: Thursday, September 12, 2013 5:28 PM > > > > To: KY Srinivasan > > > > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux- > > ker...@vger.kernel.org; > > > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > > > > jasow...@redhat.com; t...@linutronix.de; jbeul...@suse.com; > > b...@alien8.de > > > > Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer > > > > frequency > > > > from the hypervisor > > > > > > > > On 09/12/2013 05:06 PM, KY Srinivasan wrote: > > > > > > > > > > Peter, > > > > > > > > > > Let me know if you want me to address any additional issues in this > > > > > patch. > > > > > > > > > > > > > Please address Jan and Gleb's feedback. > > > > > > Gleb's feedback was a question and I answered that as I did Jan's > > > feedback as > > well. > > > Gleb, Jan, please let me know if there is something else you want > > > addressed > > here. > > > > > No, I am just interesting to know some details about the interface since > > I cannot find it documented in Hyper-V spec. > > Thanks Gleb. Here is the link for the latest Hyper-V specification: > http://www.microsoft.com/en-us/download/details.aspx?id=39289 > > This spec talks about how migration is handled with regards to TSC. > All I can see is "15.4.3 Partition Reference TSC Mechanism". I see nothing about HV_X64_MSR_TSC_FREQUENCY specifically. To access this MSR a partition needs AccessFrequencyMsrs privilege, may be partition that cab be migrated does not have this privilege? -- Gleb. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 21/24] Staging: winbond: wb35tx: Replace printk with netdev_err
On Mon, 2013-09-16 at 15:43 +0200, Iker Pedrosa wrote:
> The previously used printk lacked the warning level, now we've got a more
> accurate way to know the error.
[]
> diff --git a/drivers/staging/winbond/wb35tx.c
> b/drivers/staging/winbond/wb35tx.c
[]
> @@ -32,7 +32,7 @@ static void Wb35Tx_complete(struct urb *pUrb)
> struct wb35_tx *pWb35Tx = &pHwData->Wb35Tx;
> struct wb35_mds *pMds = &adapter->Mds;
>
> - printk("wb35: tx complete\n");
> + netdev_err(pUrb->dev, "wb35: tx complete\n");
This one should either be removed or changed to netdev_dbg
with the "wb35: " prefix removed.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: fix handle_pending_slot_free() and zram_reset_device() race
Hello,
On (09/16/13 09:02), Minchan Kim wrote:
> Hello Sergey,
>
> Sorry for really slow response. I was really busy by internal works
> and Thanks for pointing the BUG, Dan, Jerome and Sergey.
> I read your threads roughly so I may miss something. If so, sorry
> for that. Anyway I will put my opinion.
>
> On Wed, Sep 11, 2013 at 02:12:50AM +0300, Sergey Senozhatsky wrote:
> > Dan Carpenter noted that handle_pending_slot_free() is racy with
> > zram_reset_device(). Take write init_lock in zram_slot_free(), thus
>
> Right but "init_lock" is what I really want to remove.
> Yes. It's just read-side lock so most of time it doesn't hurt us but it
> makes code very complicated and deadlock prone so I'd like to replace
> it with RCU. Yeah, It's off topic but just let me put my opinion in
> future direction.
>
> Abought the bug, how about moving flush_work below down_write(init_lock)?
> zram_make_request is already closed by init_lock and we have a rule about
> lock ordering as following so I don't see any problem.
>
> init_lock
> zram->lock
>
> > preventing any concurrent zram_slot_free(), zram_bvec_rw() or
> > zram_reset_device(). This also allows to safely check zram->init_done
> > in handle_pending_slot_free().
> >
> > Initial intention was to minimze number of handle_pending_slot_free()
> > call from zram_bvec_rw(), which were slowing down READ requests due to
> > slot_free_lock spin lock. Jerome Marchand suggested to remove
> > handle_pending_slot_free() from zram_bvec_rw().
> >
> > Link: https://lkml.org/lkml/2013/9/9/172
> > Signed-off-by: Sergey Senozhatsky
> >
> > ---
> >
> > drivers/staging/zram/zram_drv.c | 13 +
> > 1 file changed, 5 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/staging/zram/zram_drv.c
> > b/drivers/staging/zram/zram_drv.c
> > index 91d94b5..7a2d4de 100644
> > --- a/drivers/staging/zram/zram_drv.c
> > +++ b/drivers/staging/zram/zram_drv.c
> > @@ -521,7 +521,8 @@ static void handle_pending_slot_free(struct zram *zram)
> > while (zram->slot_free_rq) {
> > free_rq = zram->slot_free_rq;
> > zram->slot_free_rq = free_rq->next;
> > - zram_free_page(zram, free_rq->index);
> > + if (zram->init_done)
> > + zram_free_page(zram, free_rq->index);
> > kfree(free_rq);
> > }
> > spin_unlock(&zram->slot_free_lock);
> > @@ -534,16 +535,13 @@ static int zram_bvec_rw(struct zram *zram, struct
> > bio_vec *bvec, u32 index,
> >
> > if (rw == READ) {
> > down_read(&zram->lock);
> > - handle_pending_slot_free(zram);
>
> Read side is okay but actually I have a nitpick.
> If someone poll a block in zram-swap device, he would see a block
> has zero value suddenly although there was no I/O.(I don't want to argue
> it's sane user or not, anyway) it never happens on real block device and
> it never happens on zram-block device. Only it can happen zram-swap device.
> And such behavior was there since we introduced swap_slot_free_notify.
> (off-topic: I'd like to remove it because it makes tight coupling between
> zram and swap and obviously, it was layering violation function)
> so now, I don't have strong objection.
>
> The idea is to remove swap_slot_free_notify is to use frontswap when
> user want to use zram as swap so zram can be notified when the block
> lose the owner but still we should solve the mutex problem in notify
> handler.
>
>
> > ret = zram_bvec_read(zram, bvec, index, offset, bio);
> > up_read(&zram->lock);
> > } else {
> > down_write(&zram->lock);
> > - handle_pending_slot_free(zram);
>
> Why did you remove this in write-side?
> We can't expect when the work will trigger. It means the work could remove
> valid block under the us.
>
not sure I understand how.
zram_slot_free() takes down_write(&zram->init_lock) and zram_make_request()
takes
down_read(&zram->init_lock), thus zram_slot_free() can not concurrently work
with
any RW requests. RW requests are under read() lock and zram_slot_free() is under
write() lock.
> > ret = zram_bvec_write(zram, bvec, index, offset);
> > up_write(&zram->lock);
> > }
> > -
> > return ret;
> > }
> >
> > @@ -750,12 +748,11 @@ error:
> >
> > static void zram_slot_free(struct work_struct *work)
> > {
> > - struct zram *zram;
> > + struct zram *zram = container_of(work, struct zram, free_work);
> >
> > - zram = container_of(work, struct zram, free_work);
> > - down_write(&zram->lock);
> > + down_write(&zram->init_lock);
>
> I don't like this.
> Primary problem is we should handle it as atomic so that we should use
> spinlock instead of mutex. Yeah, /me kicks his ass. From the beginning,
> I should solve this problem as that way.
>
> The simple solution popped from my mind is that
>
>
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 91d94b5..b23bf0e 100644
>
[PATCH v4] imx-drm: Fix probe failure
Since commit b5dc0d10 (drm/imx: kill firstopen callback) the following probe
failure is seen:
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
[drm] Initialized imx-drm 1.0.0 20120507 on minor 0
imx-ldb ldb.10: adding encoder failed with -16
imx-ldb: probe of ldb.10 failed with error -16
imx-ipuv3 240.ipu: IPUv3H probed
imx-ipuv3 280.ipu: IPUv3H probed
imx-ipuv3-crtc imx-ipuv3-crtc.0: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.0 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.1: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.1 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.2: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.2 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.3: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.3 failed with error -16
The reason for the probe failure is that now 'imxdrm->references' is incremented
early in imx_drm_driver_load(), so the following checks in imx_drm_add_crtc()
and imx_drm_add_encoder():
if (imxdrm->references) {
ret = -EBUSY;
goto err_busy;
}
,will always fail.
Instead of manually keeping the references in the imx-drm driver, let's use
drm->open_count.
After this patch, lvds panel is functional on a mx6qsabrelite board.
Signed-off-by: Fabio Estevam
Acked-by: Sascha Hauer
---
Greg,
The offending commit that causes the regression is in 3.12-rc1 now, so this
patch could go via your staging tree.
Changes since v3:
- Add Acked-by from Sascha
Changes since v2:
- Use imxdrm->drm->open_count for checking the references
Changes since v1:
- Improved commit log by providing an explanation to the probe failure
- Cc'ed Dave/Daniel
drivers/staging/imx-drm/imx-drm-core.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 47c5888..a2e52a0 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -41,7 +41,6 @@ struct imx_drm_device {
struct list_headencoder_list;
struct list_headconnector_list;
struct mutexmutex;
- int references;
int pipes;
struct drm_fbdev_cma*fbhelper;
};
@@ -241,8 +240,6 @@ struct drm_device *imx_drm_device_get(void)
}
}
- imxdrm->references++;
-
return imxdrm->drm;
unwind_crtc:
@@ -280,8 +277,6 @@ void imx_drm_device_put(void)
list_for_each_entry(enc, &imxdrm->encoder_list, list)
module_put(enc->owner);
- imxdrm->references--;
-
mutex_unlock(&imxdrm->mutex);
}
EXPORT_SYMBOL_GPL(imx_drm_device_put);
@@ -485,7 +480,7 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,
mutex_lock(&imxdrm->mutex);
- if (imxdrm->references) {
+ if (imxdrm->drm->open_count) {
ret = -EBUSY;
goto err_busy;
}
@@ -564,7 +559,7 @@ int imx_drm_add_encoder(struct drm_encoder *encoder,
mutex_lock(&imxdrm->mutex);
- if (imxdrm->references) {
+ if (imxdrm->drm->open_count) {
ret = -EBUSY;
goto err_busy;
}
@@ -709,7 +704,7 @@ int imx_drm_add_connector(struct drm_connector *connector,
mutex_lock(&imxdrm->mutex);
- if (imxdrm->references) {
+ if (imxdrm->drm->open_count) {
ret = -EBUSY;
goto err_busy;
}
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 00/13] hv: clean up dev_attr usage
> -Original Message- > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > Sent: Friday, September 13, 2013 11:33 AM > To: KY Srinivasan; Haiyang Zhang > Cc: de...@linuxdriverproject.org; linux-ker...@vger.kernel.org > Subject: [PATCH 00/13] hv: clean up dev_attr usage > > Hi, > > Here's a set of 13 patches to get rid of the dev_attrs use in the hv bus > code, as it will be going away soon. It's _way_ bigger than all other > conversions I've had to do so far in the kernel, as you were using a > "multiplexor" function for all of these files. > > So, I've broken it up into individual show/store sysfs functions, and > cleaned up a bunch of debug structures that aren't needed and shouldn't > be exported to the rest of the kernel. > > I've also fixed up some void * usage in the hv core, in patch 07, to > make things simpler and not so "magic" when dealing with these pages. > If you could review that one closely to ensure I didn't mess anything > up, I would appreciate it. > > Also, are all of these files really needed for sysfs? They seem to be > all debugging stuff, shouldn't they go into debugfs if you really > need/use them anymore? > > KY, could you test these out? I don't have access to a hv system at the > moment. I'll wait for your ack before applying them to any of my trees. The patches look good and I tested them. The guest comes up and is functional. I did notice though that the pending state appears to be a signed entity now which was not the the case before - I see a negative sign when I cat the client/server pending state. Regards, K. Y > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
> -Original Message- > From: Gleb Natapov [mailto:g...@redhat.com] > Sent: Tuesday, September 17, 2013 6:59 AM > To: KY Srinivasan > Cc: H. Peter Anvin; x...@kernel.org; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de; > jbeul...@suse.com; b...@alien8.de > Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency > from the hypervisor > > On Fri, Sep 13, 2013 at 02:28:35PM +, KY Srinivasan wrote: > > > > > > > -Original Message- > > > From: Gleb Natapov [mailto:g...@redhat.com] > > > Sent: Friday, September 13, 2013 2:55 AM > > > To: KY Srinivasan > > > Cc: H. Peter Anvin; x...@kernel.org; gre...@linuxfoundation.org; linux- > > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > > > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de; > > > jbeul...@suse.com; b...@alien8.de > > > Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer > > > frequency > > > from the hypervisor > > > > > > On Fri, Sep 13, 2013 at 01:43:09AM +, KY Srinivasan wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: H. Peter Anvin [mailto:h...@zytor.com] > > > > > Sent: Thursday, September 12, 2013 5:28 PM > > > > > To: KY Srinivasan > > > > > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux- > > > ker...@vger.kernel.org; > > > > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > > > > > jasow...@redhat.com; t...@linutronix.de; jbeul...@suse.com; > > > b...@alien8.de > > > > > Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer > frequency > > > > > from the hypervisor > > > > > > > > > > On 09/12/2013 05:06 PM, KY Srinivasan wrote: > > > > > > > > > > > > Peter, > > > > > > > > > > > > Let me know if you want me to address any additional issues in this > patch. > > > > > > > > > > > > > > > > Please address Jan and Gleb's feedback. > > > > > > > > Gleb's feedback was a question and I answered that as I did Jan's > > > > feedback > as > > > well. > > > > Gleb, Jan, please let me know if there is something else you want > addressed > > > here. > > > > > > > No, I am just interesting to know some details about the interface since > > > I cannot find it documented in Hyper-V spec. > > > > Thanks Gleb. Here is the link for the latest Hyper-V specification: > > http://www.microsoft.com/en-us/download/details.aspx?id=39289 > > > > This spec talks about how migration is handled with regards to TSC. > > > All I can see is "15.4.3 Partition Reference TSC Mechanism". I see > nothing about HV_X64_MSR_TSC_FREQUENCY specifically. To access this MSR > a partition needs AccessFrequencyMsrs privilege, may be partition that > cab be migrated does not have this privilege? If you use the MSR to read the TSC frequency, then indeed when you migrate then there is no guarantee that the TSC frequency won't change when you migrate. The approach described in section 15.4.3 is the preferred approach that can accommodate migration. Regards, K. Y > > -- > Gleb. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] imx-drm: Fix probe failure
On Tue, Sep 17, 2013 at 02:53:23PM -0300, Fabio Estevam wrote:
> Since commit b5dc0d10 (drm/imx: kill firstopen callback) the following probe
> failure is seen:
>
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] No driver support for vblank timestamp query.
> [drm] Initialized imx-drm 1.0.0 20120507 on minor 0
> imx-ldb ldb.10: adding encoder failed with -16
> imx-ldb: probe of ldb.10 failed with error -16
> imx-ipuv3 240.ipu: IPUv3H probed
> imx-ipuv3 280.ipu: IPUv3H probed
> imx-ipuv3-crtc imx-ipuv3-crtc.0: adding crtc failed with -16.
> imx-ipuv3-crtc: probe of imx-ipuv3-crtc.0 failed with error -16
> imx-ipuv3-crtc imx-ipuv3-crtc.1: adding crtc failed with -16.
> imx-ipuv3-crtc: probe of imx-ipuv3-crtc.1 failed with error -16
> imx-ipuv3-crtc imx-ipuv3-crtc.2: adding crtc failed with -16.
> imx-ipuv3-crtc: probe of imx-ipuv3-crtc.2 failed with error -16
> imx-ipuv3-crtc imx-ipuv3-crtc.3: adding crtc failed with -16.
> imx-ipuv3-crtc: probe of imx-ipuv3-crtc.3 failed with error -16
>
> The reason for the probe failure is that now 'imxdrm->references' is
> incremented
> early in imx_drm_driver_load(), so the following checks in imx_drm_add_crtc()
> and imx_drm_add_encoder():
>
> if (imxdrm->references) {
> ret = -EBUSY;
> goto err_busy;
> }
>
> ,will always fail.
>
> Instead of manually keeping the references in the imx-drm driver, let's use
> drm->open_count.
>
> After this patch, lvds panel is functional on a mx6qsabrelite board.
>
> Signed-off-by: Fabio Estevam
> Acked-by: Sascha Hauer
> ---
> Greg,
>
> The offending commit that causes the regression is in 3.12-rc1 now, so this
> patch could go via your staging tree.
Thanks for this, I'll take it now.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: Add dm-writeboost
On Tue, Sep 17 2013 at 8:41am -0400, Akira Hayakawa wrote: > Mike, > > First, thank you for your commenting. > I was looking forward to your comments. > > > I suppose you are sensing some "smell" in my design. > You are worrying that dm-writeboost will not only confuse users > but also fall into worst situation of giving up backward-compatibility > after merging into tree. > > That dm-writeboost's design is too eccentric as a DM target makes you so. > > That you said > > determines whether a device needs formatting, etc. Otherwise I cannot > > see how you can properly stack DM devices on writeboost devices > > (suspend+resume become tediously different) > is a proof of smell. > > Alasdair also said > > I read a statement like that as an indication of an interface or > > architectural problem. The device-mapper approach is to 'design out' > > problems, rather than relying on users not doing bad things. > > Study the existing interfaces used by other targets to understand > > some approaches that proved successful, then decide which ones > > come closest to your needs. > > and > > Mikulas said > > Another idea: > > > > Make the interface of dm-lc (the arguments to constructor, messages and > > the status line) the same as dm-cache, so that they can be driven by the > > same userspace code. > Though I guess this is going too far > since dm-writeboost and dm-cache are the different things > designing them similar definitely makes sense. > > are also sensing of smell. > > > I am afraid so I am and > I am thinking of re-designing dm-writeboost > at the fundamental architectural level. > The interfaces will be similar to that of dm-cache as a result. > > This will be a really a BIG change. > > > Probably best for you to publish the dm-writeboost code a git repo on > > github.com or the like. I just don't see what benefit there is to > > putting code like this in staging. Users already need considerable > > userspace tools and infrastructure will also be changing in the > > near-term (e.g. the migration daemon). > Yes, I agree with that regarding the current implementation. > I withdraw from the proposal for staging. > I am really sorry for Greg and others caring about dm-writeboost. > But I will be back after re-designing. OK, appreciate your willingness to rework this. > staging means lot to get 3rd party users is for sure. We don't need to go through staging. If the dm-writeboost target is designed well and provides a tangible benefit it doesn't need wide-spread users as justification for going in. The users will come if it is implemented well. > Simplify the design and > make it more possible to maintain the target > for the future is what I fully agree with. > Being adhere to cache-sharing by > risking the future maintainability doesn't pay. > Re-designing the dm-writeboost resemble to dm-cache > is a leading candidate of course. Simplifying the code is certainly desirable. So dropping the sharing sounds like a step in the right direction. Plus you can share the cache by layering multiple linear devices ontop of the dm-writeboost device. Also managing dm-writeboost devices with lvm2 is a priority, so any interface similarities dm-writeboost has with dm-cache will be beneficial. Mike ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: lustre: fix switch case statement indenting
This is a patch to lvfs_linux.c that fixes incorrect switch case statement
indenting found by checkpatch.pl.
Signed-off-by: Jon Bernard
---
drivers/staging/lustre/lustre/lvfs/lvfs_linux.c | 50 -
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
b/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
index 18e1b47..9d79eee 100644
--- a/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
+++ b/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
@@ -253,31 +253,31 @@ __s64 lprocfs_read_helper(struct lprocfs_counter *lc,
return 0;
switch (field) {
- case LPROCFS_FIELDS_FLAGS_CONFIG:
- ret = header->lc_config;
- break;
- case LPROCFS_FIELDS_FLAGS_SUM:
- ret = lc->lc_sum;
- if ((flags & LPROCFS_STATS_FLAG_IRQ_SAFE) != 0)
- ret += lc->lc_sum_irq;
- break;
- case LPROCFS_FIELDS_FLAGS_MIN:
- ret = lc->lc_min;
- break;
- case LPROCFS_FIELDS_FLAGS_MAX:
- ret = lc->lc_max;
- break;
- case LPROCFS_FIELDS_FLAGS_AVG:
- ret = (lc->lc_max - lc->lc_min) / 2;
- break;
- case LPROCFS_FIELDS_FLAGS_SUMSQUARE:
- ret = lc->lc_sumsquare;
- break;
- case LPROCFS_FIELDS_FLAGS_COUNT:
- ret = lc->lc_count;
- break;
- default:
- break;
+ case LPROCFS_FIELDS_FLAGS_CONFIG:
+ ret = header->lc_config;
+ break;
+ case LPROCFS_FIELDS_FLAGS_SUM:
+ ret = lc->lc_sum;
+ if ((flags & LPROCFS_STATS_FLAG_IRQ_SAFE) != 0)
+ ret += lc->lc_sum_irq;
+ break;
+ case LPROCFS_FIELDS_FLAGS_MIN:
+ ret = lc->lc_min;
+ break;
+ case LPROCFS_FIELDS_FLAGS_MAX:
+ ret = lc->lc_max;
+ break;
+ case LPROCFS_FIELDS_FLAGS_AVG:
+ ret = (lc->lc_max - lc->lc_min) / 2;
+ break;
+ case LPROCFS_FIELDS_FLAGS_SUMSQUARE:
+ ret = lc->lc_sumsquare;
+ break;
+ case LPROCFS_FIELDS_FLAGS_COUNT:
+ ret = lc->lc_count;
+ break;
+ default:
+ break;
};
return ret;
--
1.8.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: Add dm-writeboost
On Tue, Sep 17 2013 at 8:43am -0400, Akira Hayakawa wrote: > Hi, Mike > > There are two designs in my mind > regarding the formatting cache. > > You said > > administer the writeboost devices. There is no need for this. Just > > have a normal DM target whose .ctr takes care of validation and > > determines whether a device needs formatting, etc. > makes me wonder how I format the cache device. > > > There are two choices for formatting cache and create a writeboost device > standing on the point of removing writeboost-mgr existing in the current > design. > I will explain them from how the interface will look like. > > (1) dmsetup create myDevice ... "... $backing_path $cache_path" > which will returns error if the superblock of the given cache device > is invalid and needs formatting. > And then the user formats the cache device by some userland tool. > > (2) dmsetup create myDevice ... "... $backing_path $cache_path $do_format" > which also returns error if the superblock of the given cache device > is invalid and needs formatting when $do_format is 0. > And then user formats the cache device by setting $do_format to 1 and try > again. > > There pros and cons about the design tradeoffs: > - (i) (1) is simpler. do_format parameter in (2) doesn't seem to be sane. >(1) is like the interfaces of filesystems where dmsetup create is like > mounting a filesystem. > - (ii) (2) can implement everything in kernel. It can gather all the > information >about how the superblock in one place, kernel code. > > Excuse for the current design: > - The reason I design writeboost-mgr is almost regarding (ii) above. > writeboost-mgr has a message "format_cache_device" and > writeboost-format-cache userland command kicks the message to format cache. > > - writeboost-mgr has also a message "resume_cache" > that validates and builds a in-memory structure according to the cache > binding to given $cache_id > and user later dmsetup create the writeboost device with the $cache_id. > However, resuming the cache metadata should be done under .ctr like > dm-cache does > and should not relate LV to create and cache by external cache_id > is what I realized by looking at the code of dm-cache which > calls dm_cache_metadata_open() routines under .ctr . Right, any in-core structures should be allocated in .ctr() > writeboost-mgr is something like smell of over-engineering but > is useful for simplifying the design for above reasons. > > > Which do you think better? Have you looked at how both dm-cache and dm-thinp handle this? Userspace takes care to write all zeroes to the start of the metadata device before the first use in the kernel. In the kernel, see __superblock_all_zeroes(), the superblock on the metadata device is checked to see whether it is all 0s or not. If it is all 0s then the kernel code knows it needs to format (writing the superblock, etc). I see no reason why dm-writeboost couldn't use the same design. Also, have you looked at forking dm-cache as a starting point for dm-writeboost? It is an option, not yet clear if it'd help you as there is likely a fair amount of work picking through code that isn't relevant. But it'd be nice to have the writeboost code follow the same basic design principles. Like I mentioned before, especially if the log structured block code could be factored out. I haven't yet looked close enough at that aspect of writeboost code to know if it could benefit from the existing bio-prison code or persistent-data library at all. writeboost would obviously need a new space map type, etc. Could be the log structured nature of writeboost is very different. I'll review this closer tomorrow. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 1/1] Drivers: input: serio: New driver to support Hyper-V synthetic keyboard
Add a new driver to support synthetic keyboard. On the next generation
Hyper-V guest firmware, many legacy devices will not be emulated and this
driver will be required.
I would like to thank Vojtech Pavlik for helping me with the
details of the AT keyboard driver. I would also like to thank
Dan Carpenter and
Dmitry Torokhov for their detailed review of this
driver.
I have addressed all the comments of Dan and Dmitry in this version of
the patch
Signed-off-by: K. Y. Srinivasan
---
drivers/input/serio/Kconfig |7 +
drivers/input/serio/Makefile |1 +
drivers/input/serio/hyperv-keyboard.c | 404 +
3 files changed, 412 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/serio/hyperv-keyboard.c
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 1e691a3..f3996e7 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -267,4 +267,11 @@ config SERIO_OLPC_APSP
To compile this driver as a module, choose M here: the module will
be called olpc_apsp.
+config HYPERV_KEYBOARD
+ tristate "Microsoft Synthetic Keyboard driver"
+ depends on HYPERV
+ default HYPERV
+ help
+ Select this option to enable the Hyper-V Keyboard driver.
+
endif
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 12298b1..815d874 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_SERIO_ALTERA_PS2)+= altera_ps2.o
obj-$(CONFIG_SERIO_ARC_PS2)+= arc_ps2.o
obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o
+obj-$(CONFIG_HYPERV_KEYBOARD) += hyperv-keyboard.o
diff --git a/drivers/input/serio/hyperv-keyboard.c
b/drivers/input/serio/hyperv-keyboard.c
new file mode 100644
index 000..c327a18
--- /dev/null
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -0,0 +1,404 @@
+/*
+ * Copyright (c) 2013, Microsoft Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Current version 1.0
+ *
+ */
+#define SYNTH_KBD_VERSION_MAJOR 1
+#define SYNTH_KBD_VERSION_MINOR0
+#define SYNTH_KBD_VERSION (SYNTH_KBD_VERSION_MINOR | \
+(SYNTH_KBD_VERSION_MAJOR << 16))
+
+
+/*
+ * Message types in the synthetic input protocol
+ */
+enum synth_kbd_msg_type {
+ SYNTH_KBD_PROTOCOL_REQUEST = 1,
+ SYNTH_KBD_PROTOCOL_RESPONSE = 2,
+ SYNTH_KBD_EVENT = 3,
+ SYNTH_KBD_LED_INDICATORS = 4,
+};
+
+/*
+ * Basic message structures.
+ */
+struct synth_kbd_msg_hdr {
+ u32 type;
+};
+
+struct synth_kbd_msg {
+ struct synth_kbd_msg_hdr header;
+ char data[1]; /* Enclosed message */
+};
+
+union synth_kbd_version {
+ struct {
+ u16 minor_version;
+ u16 major_version;
+ };
+ u32 version;
+};
+
+/*
+ * Protocol messages
+ */
+struct synth_kbd_protocol_request {
+ struct synth_kbd_msg_hdr header;
+ union synth_kbd_version version_requested;
+};
+
+#define PROTOCOL_ACCEPTED BIT(0)
+struct synth_kbd_protocol_response {
+ struct synth_kbd_msg_hdr header;
+ __le32 proto_status;
+};
+
+#define IS_UNICODE BIT(0)
+#define IS_BREAK BIT(1)
+#define IS_E0 BIT(2)
+#define IS_E1 BIT(3)
+struct synth_kbd_keystroke {
+ struct synth_kbd_msg_hdr header;
+ u16 make_code;
+ u16 reserved0;
+ __le32 info; /* Additional information */
+};
+
+
+#define HK_MAXIMUM_MESSAGE_SIZE 256
+
+#define KBD_VSC_SEND_RING_BUFFER_SIZE (10 * PAGE_SIZE)
+#define KBD_VSC_RECV_RING_BUFFER_SIZE (10 * PAGE_SIZE)
+
+#define XTKBD_EMUL0 0xe0
+#define XTKBD_EMUL1 0xe1
+#define XTKBD_RELEASE 0x80
+
+
+/*
+ * Represents a keyboard device
+ */
+struct hv_kbd_dev {
+ struct hv_device*device;
+ struct synth_kbd_protocol_request protocol_req;
+ struct synth_kbd_protocol_response protocol_resp;
+ /* Synchronize the request/response if needed */
+ struct completion wait_event;
+ struct serio*hv_serio;
+};
+
+
+static struct hv_kbd_dev *hv_kbd_alloc_device(struct hv_device *device)
+{
+ struct hv_kbd_dev *kbd_dev;
+ struct serio *hv_serio;
+
+ kbd_dev = kzalloc(sizeof(struct hv_kbd_dev), GFP_KERNEL);
+ if (!kbd_dev)
+ return NULL;
+ hv_serio = kzalloc(sizeof(struct serio), GFP_
[PATCH] Staging: bcm: PHSModule.c: Matching the function definition with function declaration
From: Shalin Mehta
The function implementations of the PHSModule didn't match with the
declaration. The functions are static
in the declaration but in the implemntation they are non-static
Signed-off-by: Shalin Mehta
---
NOTE: Submitting the same patch again. Added NOTE at wrong location the
previous submission
drivers/staging/bcm/PHSModule.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/bcm/PHSModule.c b/drivers/staging/bcm/PHSModule.c
index af5d22f..56c5bee 100644
--- a/drivers/staging/bcm/PHSModule.c
+++ b/drivers/staging/bcm/PHSModule.c
@@ -596,7 +596,7 @@ ULONG PhsDeleteSFRules(IN void *pvContext, IN B_UINT16
uiVcid)
* 0 if successful,
* >0 Error.
*/
-ULONG PhsCompress(IN void *pvContext,
+static ULONG PhsCompress(IN void *pvContext,
IN B_UINT16 uiVcid,
IN B_UINT16 uiClsId,
IN void *pvInputBuffer,
@@ -677,7 +677,7 @@ ULONG PhsCompress(IN void *pvContext,
* 0 if successful,
* >0 Error.
*/
-ULONG PhsDeCompress(IN void *pvContext,
+static ULONG PhsDeCompress(IN void *pvContext,
IN B_UINT16 uiVcid,
IN void *pvInputBuffer,
OUT void *pvOutputBuffer,
@@ -829,7 +829,7 @@ UINT GetServiceFlowEntry(IN struct bcm_phs_table
*psServiceFlowTable,
return PHS_INVALID_TABLE_INDEX;
}
-UINT GetClassifierEntry(IN struct bcm_phs_classifier_table *pstClassifierTable,
+static UINT GetClassifierEntry(IN struct bcm_phs_classifier_table
*pstClassifierTable,
IN B_UINT32 uiClsid, enum bcm_phs_classifier_context
eClsContext,
OUT struct bcm_phs_classifier_entry
**ppstClassifierEntry)
{
@@ -880,7 +880,7 @@ static UINT GetPhsRuleEntry(IN struct
bcm_phs_classifier_table *pstClassifierTab
return PHS_INVALID_TABLE_INDEX;
}
-UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16 uiClsId,
+static UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16
uiClsId,
IN struct bcm_phs_table *psServiceFlowTable,
struct bcm_phs_rule *psPhsRule,
B_UINT8 u8AssociatedPHSI)
@@ -913,7 +913,7 @@ UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN
B_UINT16 uiClsId,
return uiStatus;
}
-UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
+static UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
IN B_UINT16 uiClsId,
IN struct bcm_phs_entry *pstServiceFlowEntry,
struct bcm_phs_rule *psPhsRule,
@@ -1239,7 +1239,7 @@ void DumpPhsRules(struct bcm_phs_extension
*pDeviceExtension)
* header.
* 0 -If PHS rule is NULL.If PHSI is 0 indicateing packet as
uncompressed.
*/
-int phs_decompress(unsigned char *in_buf,
+static int phs_decompress(unsigned char *in_buf,
unsigned char *out_buf,
struct bcm_phs_rule *decomp_phs_rules,
UINT *header_size)
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
On Tue, Sep 17, 2013 at 07:53:36PM +, KY Srinivasan wrote: > > > Thanks Gleb. Here is the link for the latest Hyper-V specification: > > > http://www.microsoft.com/en-us/download/details.aspx?id=39289 > > > > > > This spec talks about how migration is handled with regards to TSC. > > > > > All I can see is "15.4.3 Partition Reference TSC Mechanism". I see > > nothing about HV_X64_MSR_TSC_FREQUENCY specifically. To access this MSR > > a partition needs AccessFrequencyMsrs privilege, may be partition that > > cab be migrated does not have this privilege? > > If you use the MSR to read the TSC frequency, then indeed when you migrate > then there > is no guarantee that the TSC frequency won't change when you migrate. The > approach > described in section 15.4.3 is the preferred approach that can accommodate > migration. > Thanks. -- Gleb. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
