staging: sm750fb: Replace CamelCase variable names with underscores

[Richa Jha]

Replace CamelCase variable names with underscores to comply with
the standard kernel coding style

Signed-off-by: Richa Jha 
---
 drivers/staging/sm750fb/ddk750_chip.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 7b1180a..00bca17 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -55,7 +55,7 @@ static unsigned int get_mxclk_freq(void)
 static void set_chip_clock(unsigned int frequency)
 {
struct pll_value pll;
-   unsigned int ulActualMxClk;
+   unsigned int ul_actual_max_clk;
 
/* Cheok_0509: For SM750LE, the chip clock is fixed. Nothing to set. */
if (sm750_get_chip_type() == SM750LE)
@@ -75,7 +75,7 @@ static void set_chip_clock(unsigned int frequency)
 * Return value of sm750_calc_pll_value gives the actual
 * possible clock.
 */
-   ulActualMxClk = sm750_calc_pll_value(frequency, );
+   ul_actual_max_clk = sm750_calc_pll_value(frequency, );
 
/* Master Clock Control: MXCLK_PLL */
poke32(MXCLK_PLL_CTRL, sm750_format_pll_reg());
@@ -210,11 +210,11 @@ unsigned int ddk750_get_vm_size(void)
return data;
 }
 
-int ddk750_init_hw(struct initchip_param *pInitParam)
+int ddk750_init_hw(struct initchip_param *p_init_param)
 {
unsigned int reg;
 
-   if (pInitParam->powerMode != 0)
+   if (p_init_param->powerMode != 0)
p_init_param->powerMode = 0;
sm750_set_power_mode(p_init_param->powerMode);
 
@@ -237,13 +237,13 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
}
 
/* Set the Main Chip Clock */
-   set_chip_clock(MHz((unsigned int)pInitParam->chipClock));
+   set_chip_clock(MHz((unsigned int)p_init_param->chipClock));
 
/* Set up memory clock. */
-   set_memory_clock(MHz(pInitParam->memClock));
+   set_memory_clock(MHz(p_init_param->memClock));
 
/* Set up master clock */
-   set_master_clock(MHz(pInitParam->masterClock));
+   set_master_clock(MHz(p_init_param->masterClock));
 
/*
 * Reset the memory controller.
@@ -251,7 +251,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
 * the system might hang when sw accesses the memory.
 * The memory should be resetted after changing the MXCLK.
 */
-   if (pInitParam->resetMemory == 1) {
+   if (p_init_param->resetMemory == 1) {
reg = peek32(MISC_CTRL);
reg &= ~MISC_CTRL_LOCALMEM_RESET;
poke32(MISC_CTRL, reg);
@@ -260,7 +260,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
poke32(MISC_CTRL, reg);
}
 
-   if (pInitParam->setAllEngOff == 1) {
+   if (p_init_param->setAllEngOff == 1) {
sm750_enable_2d_engine(0);
 
/* Disable Overlay, if a former application left it on */
-- 
2.1.4


---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

staging: sm750fb: Replace functions CamelCase naming with underscores.

[Richa Jha]

Replace CamelCase function names with underscores to comply with
the standard kernel coding style

Signed-off-by: Richa Jha 
---
 drivers/staging/sm750fb/ddk750_chip.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 7b1180a..00bca17 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -55,7 +55,7 @@ static unsigned int get_mxclk_freq(void)
 static void set_chip_clock(unsigned int frequency)
 {
struct pll_value pll;
-   unsigned int ulActualMxClk;
+   unsigned int ul_actual_max_clk;
 
/* Cheok_0509: For SM750LE, the chip clock is fixed. Nothing to set. */
if (sm750_get_chip_type() == SM750LE)
@@ -75,7 +75,7 @@ static void set_chip_clock(unsigned int frequency)
 * Return value of sm750_calc_pll_value gives the actual
 * possible clock.
 */
-   ulActualMxClk = sm750_calc_pll_value(frequency, );
+   ul_actual_max_clk = sm750_calc_pll_value(frequency, );
 
/* Master Clock Control: MXCLK_PLL */
poke32(MXCLK_PLL_CTRL, sm750_format_pll_reg());
@@ -210,11 +210,11 @@ unsigned int ddk750_get_vm_size(void)
return data;
 }
 
-int ddk750_init_hw(struct initchip_param *pInitParam)
+int ddk750_init_hw(struct initchip_param *p_init_param)
 {
unsigned int reg;
 
-   if (pInitParam->powerMode != 0)
+   if (p_init_param->powerMode != 0)
p_init_param->powerMode = 0;
sm750_set_power_mode(p_init_param->powerMode);
 
@@ -237,13 +237,13 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
}
 
/* Set the Main Chip Clock */
-   set_chip_clock(MHz((unsigned int)pInitParam->chipClock));
+   set_chip_clock(MHz((unsigned int)p_init_param->chipClock));
 
/* Set up memory clock. */
-   set_memory_clock(MHz(pInitParam->memClock));
+   set_memory_clock(MHz(p_init_param->memClock));
 
/* Set up master clock */
-   set_master_clock(MHz(pInitParam->masterClock));
+   set_master_clock(MHz(p_init_param->masterClock));
 
/*
 * Reset the memory controller.
@@ -251,7 +251,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
 * the system might hang when sw accesses the memory.
 * The memory should be resetted after changing the MXCLK.
 */
-   if (pInitParam->resetMemory == 1) {
+   if (p_init_param->resetMemory == 1) {
reg = peek32(MISC_CTRL);
reg &= ~MISC_CTRL_LOCALMEM_RESET;
poke32(MISC_CTRL, reg);
@@ -260,7 +260,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
poke32(MISC_CTRL, reg);
}
 
-   if (pInitParam->setAllEngOff == 1) {
+   if (p_init_param->setAllEngOff == 1) {
sm750_enable_2d_engine(0);
 
/* Disable Overlay, if a former application left it on */
-- 
2.1.4


---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] drivers/staging/speakup: fix indent coding style problem in spk_ttyio.c

[Rui Teng]

This is a patch to the spk_ttyio.c file which fixes up the indent error
reported by the checkpatch.pl tool.

Signed-off-by: Rui Teng 
---
 drivers/staging/speakup/spk_ttyio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/spk_ttyio.c 
b/drivers/staging/speakup/spk_ttyio.c
index 6e0f042f6a44..7964a51334d9 100644
--- a/drivers/staging/speakup/spk_ttyio.c
+++ b/drivers/staging/speakup/spk_ttyio.c
@@ -61,7 +61,7 @@ static int spk_ttyio_receive_buf2(struct tty_struct *tty,
return 0;
 
/* Make sure the consumer has read buf before we have seen
- * buf_free == true and overwrite buf */
+* buf_free == true and overwrite buf */
mb();
 
ldisc_data->buf = cp[0];
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: vt6655: remove unnecessary blank lines

[Marko Stankovic]

Fix unnecessary blank lines issues reported by checkpatch.pl

Signed-off-by: Marko Stankovic 
---
 drivers/staging/vt6655/device_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 1c652f0ff3ba..78804eaec608 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1018,7 +1018,6 @@ static void vnt_interrupt_process(struct vnt_private 
*priv)
}
 
/* TODO: adhoc PS mode */
-
}
 
if (isr & ISR_BNTX) {
@@ -1702,7 +1701,6 @@ static int vt6655_suspend(struct pci_dev *pcid, 
pm_message_t state)
 
 static int vt6655_resume(struct pci_dev *pcid)
 {
-
pci_set_power_state(pcid, PCI_D0);
pci_enable_wake(pcid, PCI_D0, 0);
pci_restore_state(pcid);
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: vt6655: replace NULL comparison with '!' operator

[Marko Stankovic]

Fix comparison to NULL issues reported by checkpatch.pl

Signed-off-by: Marko Stankovic 
---
 drivers/staging/vt6655/device_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index da0f71191009..1c652f0ff3ba 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -157,7 +157,7 @@ static void vt6655_remove(struct pci_dev *pcid)
 {
struct vnt_private *priv = pci_get_drvdata(pcid);
 
-   if (priv == NULL)
+   if (!priv)
return;
device_free_info(priv);
 }
@@ -453,7 +453,7 @@ static bool device_init_rings(struct vnt_private *priv)
   priv->opts.tx_descs[0] * sizeof(struct 
vnt_tx_desc) +
   priv->opts.tx_descs[1] * sizeof(struct 
vnt_tx_desc),
   >pool_dma, GFP_ATOMIC);
-   if (vir_pool == NULL) {
+   if (!vir_pool) {
dev_err(>pcid->dev, "allocate desc dma memory failed\n");
return false;
}
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 04/10] x86/hyper-v: fast hypercall implementation

[Andy Lutomirski]

On Mon, May 22, 2017 at 3:44 AM, Vitaly Kuznetsov  wrote:
> Andy Lutomirski  writes:
>
>> On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote:
>>> Hyper-V supports 'fast' hypercalls when all parameters are passed through
>>> registers. Implement an inline version of a simpliest of these calls:
>>> hypercall with one 8-byte input and no output.
>>>
>>> Proper hypercall input interface (struct hv_hypercall_input) definition is
>>> added as well.
>>>
>>> Signed-off-by: Vitaly Kuznetsov 
>>> Acked-by: K. Y. Srinivasan 
>>> Tested-by: Simon Xiao 
>>> Tested-by: Srikanth Myakam 
>>> ---
>>>   arch/x86/include/asm/mshyperv.h| 39 
>>> ++
>>>   arch/x86/include/uapi/asm/hyperv.h | 19 +++
>>>   2 files changed, 58 insertions(+)
>>>
>>> diff --git a/arch/x86/include/asm/mshyperv.h 
>>> b/arch/x86/include/asm/mshyperv.h
>>> index e293937..028e29b 100644
>>> --- a/arch/x86/include/asm/mshyperv.h
>>> +++ b/arch/x86/include/asm/mshyperv.h
>>> @@ -216,6 +216,45 @@ static inline u64 hv_do_hypercall(u64 control, void 
>>> *input, void *output)
>>>   #endif /* !x86_64 */
>>>   }
>>>   +/* Fast hypercall with 8 bytes of input and no output */
>>> +static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
>>> +{
>>> +union hv_hypercall_input control = {0};
>>> +
>>> +control.code = code;
>>> +control.fast = 1;
>>> +#ifdef CONFIG_X86_64
>>> +{
>>> +u64 hv_status;
>>> +
>>> +__asm__ __volatile__("call *%3"
>>> + : "=a" (hv_status),
>>> +   "+c" (control.as_uint64), "+d" (input1)
>>> + : "m" (hv_hypercall_pg)
>>> + : "cc", "r8", "r9", "r10", "r11");
>>> +return hv_status;
>>> +}
>>> +#else
>>> +{
>>> +u32 hv_status_hi, hv_status_lo;
>>> +u32 input1_hi = (u32)(input1 >> 32);
>>> +u32 input1_lo = (u32)input1;
>>> +
>>> +__asm__ __volatile__ ("call *%6"
>>> +  : "=d"(hv_status_hi),
>>> +"=a"(hv_status_lo),
>>> +"+c"(input1_lo)
>>> +  : "d" (control.as_uint32_hi),
>>> +"a" (control.as_uint32_lo),
>>> +"b" (input1_hi),
>>> +"m" (hv_hypercall_pg)
>>> +  : "cc", "edi", "esi");
>>> +
>>> +return hv_status_lo | ((u64)hv_status_hi << 32);
>>> +}
>>> +#endif
>>
>> This is going to need an explicit "sp" annotation to force a stack
>> frame, I think.  Otherwise objtool is likely to get mad in a
>> frame-pointer-omitted build.
>>
>
> You mean I should do something like
>
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index 359967f..f86c4ae 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -221,6 +221,7 @@ static inline u64 hv_do_hypercall(u64 control, void 
> *input, void *output)
>  static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
>  {
> union hv_hypercall_input control = {0};
> +   register void *__sp asm(_ASM_SP);

Exactly.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] [media] atomisp: use NULL instead of 0 for pointers

[Paolo Cretaro]

Fix warning issued by sparse: Using plain integer as NULL pointer

Signed-off-by: Paolo Cretaro 
---
 drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 2 +-
 .../media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c| 2 +-
 .../media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c| 2 +-
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c  | 2 +-
 drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c  | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c 
b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
index 5e9dafe7cc32..d6447398f5ef 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
@@ -706,7 +706,7 @@ static int ov5693_read_otp_reg_array(struct i2c_client 
*client, u16 size,
 {
u16 index;
int ret;
-   u16 *pVal = 0;
+   u16 *pVal = NULL;
 
for (index = 0; index <= size; index++) {
pVal = (u16 *) (buf + index);
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c
index ed33d4c4c84a..5d40afd482f5 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c
@@ -239,7 +239,7 @@ static ia_css_queue_t *bufq_get_qhandle(
enum sh_css_queue_id id,
int thread)
 {
-   ia_css_queue_t *q = 0;
+   ia_css_queue_t *q = NULL;
 
switch (type) {
case sh_css_host2sp_buffer_queue:
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c
index b36d7b00ebe8..18966d89602a 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c
@@ -57,7 +57,7 @@ enum ia_css_err ia_css_spctrl_load_fw(sp_ID_t sp_id,
hrt_vaddress code_addr = mmgr_NULL;
struct ia_css_sp_init_dmem_cfg *init_dmem_cfg;
 
-   if ((sp_id >= N_SP_ID) || (spctrl_cfg == 0))
+   if ((sp_id >= N_SP_ID) || (spctrl_cfg == NULL))
return IA_CSS_ERR_INVALID_ARGUMENTS;
 
spctrl_cofig_info[sp_id].code_addr = mmgr_NULL;
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index 57295397da3e..5e63073f3581 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -193,7 +193,7 @@ int hmm_init(void)
 * at the beginning, to avoid hmm_alloc return 0 in the
 * further allocation.
 */
-   dummy_ptr = hmm_alloc(1, HMM_BO_PRIVATE, 0, 0, HMM_UNCACHED);
+   dummy_ptr = hmm_alloc(1, HMM_BO_PRIVATE, 0, NULL, HMM_UNCACHED);
 
if (!ret) {
ret = sysfs_create_group(_dev->kobj,
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
index 7dff22f59e29..2e78976bb2ac 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
@@ -55,7 +55,7 @@ static ia_css_ptr __hrt_isp_css_mm_alloc(size_t bytes, void 
*userptr,
if (type == HRT_USR_PTR) {
if (userptr == NULL)
return hmm_alloc(bytes, HMM_BO_PRIVATE, 0,
-0, cached);
+NULL, cached);
else {
if (num_pages < ((__page_align(bytes)) >> PAGE_SHIFT))
dev_err(atomisp_dev,
@@ -94,7 +94,7 @@ ia_css_ptr hrt_isp_css_mm_alloc_user_ptr(size_t bytes, void 
*userptr,
 ia_css_ptr hrt_isp_css_mm_alloc_cached(size_t bytes)
 {
if (my_userptr == NULL)
-   return hmm_alloc(bytes, HMM_BO_PRIVATE, 0, 0,
+   return hmm_alloc(bytes, HMM_BO_PRIVATE, 0, NULL,
HMM_CACHED);
else {
if (my_num_pages < ((__page_align(bytes)) >> PAGE_SHIFT))
-- 
2.13.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: PATCH[1/3]: comedi : submissions of contec_fit.c driver to staging/comedi/drivers

[Dan Carpenter]

On Mon, May 22, 2017 at 10:19:53AM -0500, Dan Naughton wrote:
> Adding new driver to drivers/staging/comedi/drivers for contec_fit.c
> for CONTEC F modules
> 
> Signed off by dan.naugh...@dtx.com

Checkpatch would have complained about this Signed-off-by: line.  Please
use your full legal name as if you were signing a legal document.  Run
checkpatch.pl --strict over your patch.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/5] vmbus: implement lock-less ring buffer

[Stephen Hemminger]

On Mon, 22 May 2017 11:28:18 -0700
Stephen Hemminger  wrote:

> On Sun, 21 May 2017 18:09:59 +
> KY Srinivasan  wrote:
> 
> > > -Original Message-
> > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > Sent: Thursday, May 18, 2017 9:25 AM
> > > To: KY Srinivasan ; gre...@linuxfoundation.org
> > > Cc: de...@linuxdriverproject.org; Stephen Hemminger
> > > 
> > > Subject: [PATCH 2/5] vmbus: implement lock-less ring buffer
> > > 
> > > Use a reservation similar to ftrace to make vmbus ring buffer writes
> > > lock free.
> > > 
> > > The algorithm uses cmpxchg to atomically reserve an area in the ring
> > > buffer. Then the data is copied into the ring, and the updates to the
> > > head of the ring are ordered.
> > > 
> > > Other similar implementions are FreeBSD buf_ring, and DPDK rte_ring.
> > > 
> > > Signed-off-by: Stephen Hemminger   
> 
> 
> I did some detailed measurements. The locked version takes 89.8ns average to 
> write to
> ring buffer, and the cmpxchg version takes 94.7ns.  The difference is that 
> the locked
> version has longer tail of distribution. Some most common for both cases is 
> 80ns.
> 
> Let's skip this patch.

I will make a new version with locks, but uses the simplified memcpy code.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/5] vmbus: implement lock-less ring buffer

[Stephen Hemminger]

On Sun, 21 May 2017 18:09:59 +
KY Srinivasan  wrote:

> > -Original Message-
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Thursday, May 18, 2017 9:25 AM
> > To: KY Srinivasan ; gre...@linuxfoundation.org
> > Cc: de...@linuxdriverproject.org; Stephen Hemminger
> > 
> > Subject: [PATCH 2/5] vmbus: implement lock-less ring buffer
> > 
> > Use a reservation similar to ftrace to make vmbus ring buffer writes
> > lock free.
> > 
> > The algorithm uses cmpxchg to atomically reserve an area in the ring
> > buffer. Then the data is copied into the ring, and the updates to the
> > head of the ring are ordered.
> > 
> > Other similar implementions are FreeBSD buf_ring, and DPDK rte_ring.
> > 
> > Signed-off-by: Stephen Hemminger 


I did some detailed measurements. The locked version takes 89.8ns average to 
write to
ring buffer, and the cmpxchg version takes 94.7ns.  The difference is that the 
locked
version has longer tail of distribution. Some most common for both cases is 
80ns.

Let's skip this patch.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB flush

[Andy Lutomirski]

On Mon, May 22, 2017 at 3:43 AM, Vitaly Kuznetsov  wrote:
> Andy Lutomirski  writes:
>
>> On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote:
>>> Hyper-V host can suggest us to use hypercall for doing remote TLB flush,
>>> this is supposed to work faster than IPIs.
>>>
>>> Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls
>>> we need to put the input somewhere in memory and we don't really want to
>>> have memory allocation on each call so we pre-allocate per cpu memory areas
>>> on boot. These areas are of fixes size, limit them with an arbitrary number
>>> of 16 (16 gvas are able to specify 16 * 4096 pages).
>>>
>>> pv_ops patching is happening very early so we need to separate
>>> hyperv_setup_mmu_ops() and hyper_alloc_mmu().
>>>
>>> It is possible and easy to implement local TLB flushing too and there is
>>> even a hint for that. However, I don't see a room for optimization on the
>>> host side as both hypercall and native tlb flush will result in vmexit. The
>>> hint is also not set on modern Hyper-V versions.
>>
>> Why do local flushes exit?
>
> "exist"? I don't know, to be honest. To me it makes no difference from
> hypervisor's point of view as intercepting tlb flushing instructions is
> not any different from implmenting a hypercall.
>
> Hyper-V gives its guests 'hints' to indicate if they need to use
> hypercalls for remote/locat TLB flush and I don't remember seeing
> 'local' bit set.

What I meant was: why aren't local flushes handled directly in the
guest without exiting to the host?  Or are they?  In principle,
INVPCID should just work, right?  Even reading and writing CR3 back
should work if the hypervisor sets up the magic list of allowed CR3
values, right?

I guess on older CPUs there might not be any way to flush the local
TLB without exiting, but I'm not *that* familiar with the details of
the virtualization extensions.

>
>>
>>> +static void hyperv_flush_tlb_others(const struct cpumask *cpus,
>>> +struct mm_struct *mm, unsigned long start,
>>> +unsigned long end)
>>> +{
>>
>> What tree will this go through?  I'm about to send a signature change
>> for this function for tip:x86/mm.
>
> I think this was going to get through Greg's char-misc tree but if we
> need to synchronize I think we can push this through x86.

Works for me.  Linus can probably resolve the trivial conflict.  But
going through the x86 tree might make sense here if that's okay with
you.

>
>>
>> Also, how would this interact with PCID?  I have PCID patches that I'm
>> pretty happy with now, and I'm hoping to support PCID in 4.13.
>>
>
> Sorry, I wasn't following this work closely. .flush_tlb_others() hook is
> not going away from pv_mmu_ops, right? In think case we can have both in
> 4.13. Or do you see any other clashes?
>

The issue is that I'm changing the whole flush algorithm.  The main
patch that affects this is here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pcid=a67bff42e1e55666fdbaddf233a484a8773688c1

The interactions between that patch and paravirt flush helpers may be
complex, and it'll need some thought.  PCID makes everything even more
subtle, so just turning off PCID when paravirt flush is involved seems
the safest for now.  Ideally we'd eventually support PCID and paravirt
flushes together (and even eventual native remote flushes assuming
they ever get added).

Also, can you share the benchmark you used for these patches?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] vmbus: remove no longer used per_channel_state

[Stephen Hemminger]

The per_channel_state in vmbus_channel struct is no longer
used by any vmbus device and can be removed now.

Signed-off-by: Stephen Hemminger 
---
 include/linux/hyperv.h | 14 --
 1 file changed, 14 deletions(-)

diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index e09fc8290c2f..5dc4323e6f30 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -843,10 +843,6 @@ struct vmbus_channel {
 */
struct vmbus_channel *primary_channel;
/*
-* Support per-channel state for use by vmbus drivers.
-*/
-   void *per_channel_state;
-   /*
 * To support per-cpu lookup mapping of relid to channel,
 * link up channels based on their CPU affinity.
 */
@@ -916,16 +912,6 @@ static inline void set_channel_read_mode(struct 
vmbus_channel *c,
c->callback_mode = mode;
 }
 
-static inline void set_per_channel_state(struct vmbus_channel *c, void *s)
-{
-   c->per_channel_state = s;
-}
-
-static inline void *get_per_channel_state(struct vmbus_channel *c)
-{
-   return c->per_channel_state;
-}
-
 static inline void set_channel_pending_send_size(struct vmbus_channel *c,
 u32 size)
 {
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

comedi contec_fit.c patch - please disregard - I will resend

[Dan Naughton]

Please disregard the last patch submissions [3] for including the
contec_fit.c driver.  The line wrapping was incorrect, and the patch
should be a single patch - not three - to add the driver.

Sorry for the mistake.

Dan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: PATCH[3/3]: comedi : modify Makefile to include contec_fit.c driver in staging/comedi/drivers

[Greg KH]

On Mon, May 22, 2017 at 10:21:21AM -0500, Dan Naughton wrote:
> modified Makefile in /drivers/staging/comedi/drivers to include
> contec_fit.c module

Why not do all of this in a single patch?  No need to spread it out to 3
different ones.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: PATCH[1/3]: comedi : submissions of contec_fit.c driver to staging/comedi/drivers

[Greg KH]

On Mon, May 22, 2017 at 10:19:53AM -0500, Dan Naughton wrote:
> Adding new driver to drivers/staging/comedi/drivers for contec_fit.c
> for CONTEC F modules
> 
> Signed off by dan.naugh...@dtx.com

Please use scripts/checkpatch.pl on your patches to check things before
sending them in.

Also use scripts/get_maintainer.pl to determine _who_ to send the
patches to.

> 
> diff -ruN linux.bak/drivers/staging/comedi/drivers/contec_fit.c
> linux/drivers/staging/comedi/drivers/contec_fit.c
> --- linux.bak/drivers/staging/comedi/drivers/contec_fit.c
> 1969-12-31 18:00:00.0 -0600
> +++ linux/drivers/staging/comedi/drivers/contec_fit.c2017-05-20
> 15:02:03.715167366 -0500

Your patch is line-wrapped, and tabs all are converted to spaces, making
this patch impossible to apply, even if I wanted to :(

Please fix up and resend the whole series.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

PATCH[3/3]: comedi : modify Makefile to include contec_fit.c driver in staging/comedi/drivers

[Dan Naughton]

modified Makefile in /drivers/staging/comedi/drivers to include
contec_fit.c module


Signed off by dan.naugh...@dtx.com

diff -ruN linux.bak/drivers/staging/comedi/drivers/Makefile
linux/drivers/staging/comedi/drivers/Makefile
--- linux.bak/drivers/staging/comedi/drivers/Makefile2017-05-05
10:09:26.246553440 -0500
+++ linux/drivers/staging/comedi/drivers/Makefile2017-05-20
16:34:34.707081106 -0500
@@ -89,6 +89,7 @@
 obj-$(CONFIG_COMEDI_AMPLC_PCI224)+= amplc_pci224.o
 obj-$(CONFIG_COMEDI_AMPLC_PCI230)+= amplc_pci230.o
 obj-$(CONFIG_COMEDI_CONTEC_PCI_DIO)+= contec_pci_dio.o
+obj-$(CONFIG_COMEDI_CONTEC_FIT)+= contec_fit.o
 obj-$(CONFIG_COMEDI_DAS08_PCI)+= das08_pci.o
 obj-$(CONFIG_COMEDI_DT3000)+= dt3000.o
 obj-$(CONFIG_COMEDI_DYNA_PCI10XX)+= dyna_pci10xx.o
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

PATCH[2/3]: comedi : modify Kconfig to include contec_fit.c driver in staging/comedi

[Dan Naughton]

Modified Kconfig in drivers/staging/comedi to include contec_fit.c

Signed off by dan.naugh...@dtx.com

diff -ruN linux.bak/drivers/staging/comedi/Kconfig
linux/drivers/staging/comedi/Kconfig
--- linux.bak/drivers/staging/comedi/Kconfig2017-05-05
10:16:32.948968889 -0500
+++ linux/drivers/staging/comedi/Kconfig2017-05-20 16:06:32.704221635 -0500
@@ -847,6 +847,15 @@
   To compile this driver as a module, choose M here: the module will be
   called contec_pci_dio.

+config COMEDI_CONTEC_FIT
+tristate "CONTEC FeIT modules"
+---help---
+Enable support for CONTEC FeIT modules
+
+To compile this driver as a module, chose M here: the module will be
+called contec_fit
+
+
 config COMEDI_DAS08_PCI
 tristate "DAS-08 PCI support"
 select COMEDI_DAS08
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

PATCH[1/3]: comedi : submissions of contec_fit.c driver to staging/comedi/drivers

[Dan Naughton]

Adding new driver to drivers/staging/comedi/drivers for contec_fit.c
for CONTEC F modules

Signed off by dan.naugh...@dtx.com

diff -ruN linux.bak/drivers/staging/comedi/drivers/contec_fit.c
linux/drivers/staging/comedi/drivers/contec_fit.c
--- linux.bak/drivers/staging/comedi/drivers/contec_fit.c
1969-12-31 18:00:00.0 -0600
+++ linux/drivers/staging/comedi/drivers/contec_fit.c2017-05-20
15:02:03.715167366 -0500
@@ -0,0 +1,908 @@
+/*
+comedi/drivers/contec_fit.c
+
+COMEDI - Linux Control and Measurement Device Interface
+Copyright (C) 2000 David A. Schleef 
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that 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.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+*/
+/*
+Driver: contec_fit
+Description: Contec F series modules
+Devices: [Contec] DAI12-4(FIT)GY (contec_fit), ADI16-4(FIT)GY, DIO-8/8(FIT)GY
+Author: Contec Co., Ltd.
+Updated: Thu, 18 May 2017 14:30:00 +0900
+Status: works
+
+Configuration Options:
+  [0] - DeviceID of module (optional)
+  If DeviceID is not specified, DeviceID 0 will be used.
+*/
+
+#include 
+#include 
+#include "../comedidev.h"
+#include 
+
+typedef struct {
+struct task_struct *fit_kthread;
+} contec_fit_private;
+
+#define devpriv ((contec_fit_private *)dev->private)
+
+static int contec_attach(struct comedi_device * dev, struct
comedi_devconfig * it);
+static void contec_detach(struct comedi_device * dev);
+static struct comedi_driver driver_contec = {
+  .driver_name= "contec_fit",
+  .module= THIS_MODULE,
+  .attach= contec_attach,
+  .detach= contec_detach,
+};
+
+/* Classic digital IO */
+static int contec_ai_insn_read(struct comedi_device * dev, struct
comedi_subdevice * s, struct comedi_insn * insn, unsigned int * data);
+static int contec_ao_insn_write(struct comedi_device * dev, struct
comedi_subdevice * s, struct comedi_insn * insn, unsigned int * data);
+static int contec_di_insn_bits(struct comedi_device * dev, struct
comedi_subdevice * s, struct comedi_insn * insn, unsigned int * data);
+static int contec_do_insn_bits(struct comedi_device * dev, struct
comedi_subdevice * s, struct comedi_insn * insn, unsigned int * data);
+
+staticint contec_ai_cmdtest(struct comedi_device * dev, struct
comedi_subdevice * s, struct comedi_cmd * cmd);
+static int contec_ai_cmd(struct comedi_device * dev, struct
comedi_subdevice * s);
+static int contec_ai_sampling_thread(void * context_dev);
+static int contec_ai_cancel(struct comedi_device * dev, struct
comedi_subdevice * s);
+
+staticint contec_ao_cmdtest(struct comedi_device * dev, struct
comedi_subdevice * s, struct comedi_cmd * cmd);
+static int contec_ao_cmd(struct comedi_device * dev, struct
comedi_subdevice * s);
+static int contec_ao_sampling_thread(void * context_dev);
+static int contec_ao_cancel(struct comedi_device * dev, struct
comedi_subdevice * s);
+static int contec_ao_cmd_inttrig(struct comedi_device *dev, struct
comedi_subdevice *s, unsigned int trignum);
+
+static void contec_check_sampling_clock(unsigned int *sampling_clock,
unsigned int *channel_num, int flags);
+
+//START ADDRESS
+#define ADDRESS_BASE0x0800
+#define ADDRESS_PER_ID0x1000
+
+//CONTEC FIT SIZE
+#define CONTEC_FIT_SIZE0x20
+
+//COMMON IO
+#define IO_PRODUCT_CATEGORY0x00
+#define IO_PRODUCT_ID_NUMBER0x01
+#define IO_COMMAND_DATA0x18
+#define IO_SETUP_DATA00x1C
+#define IO_SETUP_DATA10x1D
+#define IO_SETUP_DATA20x1E
+#define IO_SETUP_DATA30x1F
+
+//DAI12-4(FIT)GY IO
+#define IO_DAI124_OUTPUTDATA_LOWER0x10
+#define IO_DAI124_OUTPUTDATA_UPPER0x11
+#define IO_DAI124_CHANNELDATA0x12
+#define IO_DAI124_STATUS0x16
+
+//ADI16-4(FIT)GY IO
+#define IO_ADI164_INPUTDATA_LOWER0x10
+#define IO_ADI164_INPUTDATA_UPPER0x11
+#define IO_ADI164_CHANNELDATA0x12
+#define IO_ADI164_STATUS00x16
+#define IO_ADI164_STATUS10x17
+
+//DIO-8/8(FIT)GY IO
+#define IO_DIO88_INPUT00x10
+#define IO_DIO88_OUTPUT00x14
+
+//DAI12-4(FIT)GY COMMAND
+#define COMMAND_DAI124_INIT   

RE: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB flush

[KY Srinivasan]

> -Original Message-
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Vitaly Kuznetsov
> Sent: Monday, May 22, 2017 3:44 AM
> To: Andy Lutomirski 
> Cc: Stephen Hemminger ; Jork Loeser
> ; Haiyang Zhang ;
> x...@kernel.org; linux-ker...@vger.kernel.org; Steven Rostedt
> ; Ingo Molnar ; H. Peter Anvin
> ; de...@linuxdriverproject.org; Thomas Gleixner
> 
> Subject: Re: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB
> flush
> 
> Andy Lutomirski  writes:
> 
> > On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote:
> >> Hyper-V host can suggest us to use hypercall for doing remote TLB flush,
> >> this is supposed to work faster than IPIs.
> >>
> >> Implementation details: to do HvFlushVirtualAddress{Space,List}
> hypercalls
> >> we need to put the input somewhere in memory and we don't really
> want to
> >> have memory allocation on each call so we pre-allocate per cpu memory
> areas
> >> on boot. These areas are of fixes size, limit them with an arbitrary number
> >> of 16 (16 gvas are able to specify 16 * 4096 pages).
> >>
> >> pv_ops patching is happening very early so we need to separate
> >> hyperv_setup_mmu_ops() and hyper_alloc_mmu().
> >>
> >> It is possible and easy to implement local TLB flushing too and there is
> >> even a hint for that. However, I don't see a room for optimization on the
> >> host side as both hypercall and native tlb flush will result in vmexit. The
> >> hint is also not set on modern Hyper-V versions.
> >
> > Why do local flushes exit?
> 
> "exist"? I don't know, to be honest. To me it makes no difference from
> hypervisor's point of view as intercepting tlb flushing instructions is
> not any different from implmenting a hypercall.
> 
> Hyper-V gives its guests 'hints' to indicate if they need to use
> hypercalls for remote/locat TLB flush and I don't remember seeing
> 'local' bit set.
> 
> Microsoft folks may probably shed some light on why this was added.

As Vitaly has indicated, these are based on hints from the hypervisor.
Not sure what the perf impact might be for the local flush enlightenment.
> 
> >
> >> +static void hyperv_flush_tlb_others(const struct cpumask *cpus,
> >> +  struct mm_struct *mm, unsigned long
> start,
> >> +  unsigned long end)
> >> +{
> >
> > What tree will this go through?  I'm about to send a signature change
> > for this function for tip:x86/mm.
> 
> I think this was going to get through Greg's char-misc tree but if we
> need to synchronize I think we can push this through x86.

It will be good to take this through Greg's tree as that would simplify 
coordination
with other changes. 
> 
> >
> > Also, how would this interact with PCID?  I have PCID patches that I'm
> > pretty happy with now, and I'm hoping to support PCID in 4.13.
> >
> 
> Sorry, I wasn't following this work closely. .flush_tlb_others() hook is
> not going away from pv_mmu_ops, right? In think case we can have both in
> 4.13. Or do you see any other clashes?
> 
> --
>   Vitaly
> ___
> devel mailing list
> de...@linuxdriverproject.org
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdriverd
> ev.linuxdriverproject.org%2Fmailman%2Flistinfo%2Fdriverdev-
> devel=02%7C01%7Ckys%40microsoft.com%7Cbdee6af479524fb02db50
> 8d4a0ff73fe%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63631046
> 6477893081=69mm5horEX93QjLCyhvyFwD8CL%2B0M8kJFaWC9%2BW
> 18wc%3D=0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Fixed cameCase check in file drivers/staging/sm750fb/ddk750_chip.c

[Greg KH]

On Mon, May 22, 2017 at 05:41:31PM +0530, Richa Jha wrote:
> Changes :
> 
> ulActualMxClk ---> ul_actual_max_clk
> pInitParam---> p_init_param

I can see that from the patch, but _why_ are you doing this?

And please fix up your subject to match others for this driver, you can
find that in 'git log FILENAME'

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] drivers/staging/speakup: fix some coding style problem in spk_ttyio.c

[Greg Kroah-Hartman]

On Sun, May 21, 2017 at 02:43:47AM +0800, Rui Teng wrote:
> This is a patch to the spk_ttyio.c file which fixes up the problems
> reported by the checkpatch.pl tool.

"the problems reported" is very very very vague.

Please read my last email to you...

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] drivers/staging/speakup: fix some coding style problem in spk_ttyio.c

[Rui Teng]

This is a patch to the spk_ttyio.c file which fixes up the problems
reported by the checkpatch.pl tool.

Signed-off-by: Rui Teng 
---
 drivers/staging/speakup/spk_ttyio.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/speakup/spk_ttyio.c 
b/drivers/staging/speakup/spk_ttyio.c
index 6e0f042f6a44..791da6e6d6ed 100644
--- a/drivers/staging/speakup/spk_ttyio.c
+++ b/drivers/staging/speakup/spk_ttyio.c
@@ -25,10 +25,8 @@ static int spk_ttyio_ldisc_open(struct tty_struct *tty)
speakup_tty = tty;
 
ldisc_data = kmalloc(sizeof(struct spk_ldisc_data), GFP_KERNEL);
-   if (!ldisc_data) {
-   pr_err("speakup: Failed to allocate ldisc_data.\n");
+   if (!ldisc_data)
return -ENOMEM;
-   }
 
sema_init(_data->sem, 0);
ldisc_data->buf_free = true;
@@ -50,6 +48,7 @@ static int spk_ttyio_receive_buf2(struct tty_struct *tty,
 
if (spk_ttyio_synth->read_buff_add) {
int i;
+
for (i = 0; i < count; i++)
spk_ttyio_synth->read_buff_add(cp[i]);
 
@@ -61,7 +60,8 @@ static int spk_ttyio_receive_buf2(struct tty_struct *tty,
return 0;
 
/* Make sure the consumer has read buf before we have seen
- * buf_free == true and overwrite buf */
+* buf_free == true and overwrite buf
+*/
mb();
 
ldisc_data->buf = cp[0];
@@ -162,6 +162,7 @@ static int spk_ttyio_out(struct spk_synth *in_synth, const 
char ch)
 {
if (in_synth->alive && speakup_tty && speakup_tty->ops->write) {
int ret = speakup_tty->ops->write(speakup_tty, , 1);
+
if (ret == 0)
/* No room */
return 0;
@@ -204,7 +205,8 @@ static unsigned char ttyio_in(int timeout)
 
rv = ldisc_data->buf;
/* Make sure we have read buf before we set buf_free to let
-* the producer overwrite it */
+* the producer overwrite it
+*/
mb();
ldisc_data->buf_free = true;
/* Let TTY push more characters */
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Fixed cameCase check in file drivers/staging/sm750fb/ddk750_chip.c

[Richa Jha]

Changes :

ulActualMxClk ---> ul_actual_max_clk
pInitParam---> p_init_param

Signed-off-by: Richa Jha 
---
 drivers/staging/sm750fb/ddk750_chip.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 7b1180a..00bca17 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -55,7 +55,7 @@ static unsigned int get_mxclk_freq(void)
 static void set_chip_clock(unsigned int frequency)
 {
struct pll_value pll;
-   unsigned int ulActualMxClk;
+   unsigned int ul_actual_max_clk;
 
/* Cheok_0509: For SM750LE, the chip clock is fixed. Nothing to set. */
if (sm750_get_chip_type() == SM750LE)
@@ -75,7 +75,7 @@ static void set_chip_clock(unsigned int frequency)
 * Return value of sm750_calc_pll_value gives the actual
 * possible clock.
 */
-   ulActualMxClk = sm750_calc_pll_value(frequency, );
+   ul_actual_max_clk = sm750_calc_pll_value(frequency, );
 
/* Master Clock Control: MXCLK_PLL */
poke32(MXCLK_PLL_CTRL, sm750_format_pll_reg());
@@ -210,11 +210,11 @@ unsigned int ddk750_get_vm_size(void)
return data;
 }
 
-int ddk750_init_hw(struct initchip_param *pInitParam)
+int ddk750_init_hw(struct initchip_param *p_init_param)
 {
unsigned int reg;
 
-   if (pInitParam->powerMode != 0)
+   if (p_init_param->powerMode != 0)
p_init_param->powerMode = 0;
sm750_set_power_mode(p_init_param->powerMode);
 
@@ -237,13 +237,13 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
}
 
/* Set the Main Chip Clock */
-   set_chip_clock(MHz((unsigned int)pInitParam->chipClock));
+   set_chip_clock(MHz((unsigned int)p_init_param->chipClock));
 
/* Set up memory clock. */
-   set_memory_clock(MHz(pInitParam->memClock));
+   set_memory_clock(MHz(p_init_param->memClock));
 
/* Set up master clock */
-   set_master_clock(MHz(pInitParam->masterClock));
+   set_master_clock(MHz(p_init_param->masterClock));
 
/*
 * Reset the memory controller.
@@ -251,7 +251,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
 * the system might hang when sw accesses the memory.
 * The memory should be resetted after changing the MXCLK.
 */
-   if (pInitParam->resetMemory == 1) {
+   if (p_init_param->resetMemory == 1) {
reg = peek32(MISC_CTRL);
reg &= ~MISC_CTRL_LOCALMEM_RESET;
poke32(MISC_CTRL, reg);
@@ -260,7 +260,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
poke32(MISC_CTRL, reg);
}
 
-   if (pInitParam->setAllEngOff == 1) {
+   if (p_init_param->setAllEngOff == 1) {
sm750_enable_2d_engine(0);
 
/* Disable Overlay, if a former application left it on */
-- 
2.1.4


---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/5][v5] staging: fsl-mc: move bus driver out of staging

[laurentiu.tudor]

From: Stuart Yoder 

Move the source files out of staging into their final locations:
  -include files in drivers/staging/fsl-mc/include go to include/linux/fsl
  -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
  -source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
  -README.txt, providing and overview of DPAA goes to
   Documentation/dpaa2/overview.txt

Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
Update dpaa2_eth and dpio staging drivers.

Signed-off-by: Stuart Yoder 
Signed-off-by: Laurentiu Tudor 
[Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
---

Notes:
-v5
  -no changes
-v4
  -rebased
  -update existing dpaa2 drivers to work with the bus out of staging
-v3
  -no changes
-v2
  -updated MAINTAINERS with new location

 .../README.txt => Documentation/dpaa2/overview.txt|  0
 MAINTAINERS   |  2 +-
 drivers/bus/Kconfig   |  2 ++
 drivers/bus/Makefile  |  3 +++
 drivers/bus/fsl-mc/Kconfig| 17 +
 drivers/bus/fsl-mc/Makefile   | 19 +++
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h |  0
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c |  6 +++---
 .../{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h|  0
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c|  4 ++--
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h|  0
 .../{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h|  0
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c|  6 +++---
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h |  0
 .../{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c  |  4 ++--
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c |  6 +++---
 .../fsl-mc/bus => bus/fsl-mc}/fsl-mc-allocator.c  |  6 +++---
 .../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-bus.c   |  6 +++---
 .../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-msi.c   |  5 +++--
 .../fsl-mc/bus => bus/fsl-mc}/fsl-mc-private.h|  2 +-
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-io.c|  5 +++--
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-sys.c   |  6 +++---
 drivers/irqchip/Makefile  |  1 +
 .../bus => irqchip}/irq-gic-v3-its-fsl-mc-msi.c   |  3 +--
 drivers/staging/fsl-dpaa2/ethernet/README |  2 +-
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c|  4 ++--
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h|  2 +-
 drivers/staging/fsl-dpaa2/ethernet/dpni.c |  4 ++--
 drivers/staging/fsl-mc/TODO   | 18 --
 drivers/staging/fsl-mc/bus/Kconfig| 10 --
 drivers/staging/fsl-mc/bus/Makefile   | 15 +--
 drivers/staging/fsl-mc/bus/dpcon.c|  8 
 drivers/staging/fsl-mc/bus/dpio/dpio-driver.c |  2 +-
 drivers/staging/fsl-mc/bus/dpio/dpio-service.c|  2 +-
 drivers/staging/fsl-mc/bus/dpio/dpio.c|  4 ++--
 .../fsl-mc/include => include/linux/fsl}/dpbp.h   |  0
 .../fsl-mc/bus => include/linux/fsl}/dpcon-cmd.h  |  0
 .../fsl-mc/include => include/linux/fsl}/dpmng.h  |  0
 .../fsl-mc/include => include/linux/fsl}/dprc.h   |  1 -
 .../fsl-mc/include => include/linux/fsl}/mc-bus.h |  2 +-
 .../fsl-mc/include => include/linux/fsl}/mc-cmd.h |  0
 .../fsl-mc/include => include/linux/fsl}/mc-sys.h |  0
 .../staging/fsl-mc/include => include/linux/fsl}/mc.h |  2 +-
 43 files changed, 90 insertions(+), 89 deletions(-)
 rename drivers/staging/fsl-mc/README.txt => Documentation/dpaa2/overview.txt 
(100%)
 create mode 100644 drivers/bus/fsl-mc/Kconfig
 create mode 100644 drivers/bus/fsl-mc/Makefile
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h (100%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c (98%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h (100%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c (98%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h (100%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h (100%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c (96%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h (100%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c (99%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c (99%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-allocator.c (99%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-bus.c (99%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-msi.c (99%)
 rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-private.h 

[PATCH 1/5][v2] staging: fsl-mc: fix several checkpath.pl warnings

[laurentiu.tudor]

From: Laurentiu Tudor 

Remove several unneeded #includes, forward
declarations and fix several issues reported
by checkpatch.pl --strict, such as:
 - kfree(NULL) is safe and check is not required
 - macro argument reuse may cause possible side effects
 - enclose macro params in parens to avoid precedence issues
 - coding style

Signed-off-by: Laurentiu Tudor 
---

Notes:
-v2
  -no changes

 drivers/staging/fsl-mc/bus/dpbp-cmd.h |  2 +-
 drivers/staging/fsl-mc/bus/dpmcp-cmd.h|  2 +-
 drivers/staging/fsl-mc/bus/dpmng-cmd.h|  2 +-
 drivers/staging/fsl-mc/bus/dprc-cmd.h |  2 +-
 drivers/staging/fsl-mc/bus/dprc-driver.c  | 10 +++---
 drivers/staging/fsl-mc/bus/fsl-mc-allocator.c | 11 +++
 drivers/staging/fsl-mc/bus/fsl-mc-bus.c   | 12 +++-
 drivers/staging/fsl-mc/bus/fsl-mc-msi.c   |  1 +
 drivers/staging/fsl-mc/bus/fsl-mc-private.h   |  1 -
 drivers/staging/fsl-mc/include/dprc.h |  3 ---
 drivers/staging/fsl-mc/include/mc-sys.h   |  1 -
 11 files changed, 22 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dpbp-cmd.h 
b/drivers/staging/fsl-mc/bus/dpbp-cmd.h
index 8aa6545..5904836 100644
--- a/drivers/staging/fsl-mc/bus/dpbp-cmd.h
+++ b/drivers/staging/fsl-mc/bus/dpbp-cmd.h
@@ -40,7 +40,7 @@
 #define DPBP_CMD_BASE_VERSION  1
 #define DPBP_CMD_ID_OFFSET 4
 
-#define DPBP_CMD(id)   ((id << DPBP_CMD_ID_OFFSET) | DPBP_CMD_BASE_VERSION)
+#define DPBP_CMD(id)   (((id) << DPBP_CMD_ID_OFFSET) | DPBP_CMD_BASE_VERSION)
 
 /* Command IDs */
 #define DPBP_CMDID_CLOSE   DPBP_CMD(0x800)
diff --git a/drivers/staging/fsl-mc/bus/dpmcp-cmd.h 
b/drivers/staging/fsl-mc/bus/dpmcp-cmd.h
index 384a13d..861b2a7 100644
--- a/drivers/staging/fsl-mc/bus/dpmcp-cmd.h
+++ b/drivers/staging/fsl-mc/bus/dpmcp-cmd.h
@@ -40,7 +40,7 @@
 #define DPMCP_CMD_BASE_VERSION 1
 #define DPMCP_CMD_ID_OFFSET4
 
-#define DPMCP_CMD(id)  ((id << DPMCP_CMD_ID_OFFSET) | DPMCP_CMD_BASE_VERSION)
+#define DPMCP_CMD(id)  (((id) << DPMCP_CMD_ID_OFFSET) | DPMCP_CMD_BASE_VERSION)
 
 /* Command IDs */
 #define DPMCP_CMDID_CLOSE  DPMCP_CMD(0x800)
diff --git a/drivers/staging/fsl-mc/bus/dpmng-cmd.h 
b/drivers/staging/fsl-mc/bus/dpmng-cmd.h
index cdddfb8..d1f04ac 100644
--- a/drivers/staging/fsl-mc/bus/dpmng-cmd.h
+++ b/drivers/staging/fsl-mc/bus/dpmng-cmd.h
@@ -44,7 +44,7 @@
 #define DPMNG_CMD_BASE_VERSION 1
 #define DPMNG_CMD_ID_OFFSET4
 
-#define DPMNG_CMD(id)  ((id << DPMNG_CMD_ID_OFFSET) | DPMNG_CMD_BASE_VERSION)
+#define DPMNG_CMD(id)  (((id) << DPMNG_CMD_ID_OFFSET) | DPMNG_CMD_BASE_VERSION)
 
 /* Command IDs */
 #define DPMNG_CMDID_GET_VERSIONDPMNG_CMD(0x831)
diff --git a/drivers/staging/fsl-mc/bus/dprc-cmd.h 
b/drivers/staging/fsl-mc/bus/dprc-cmd.h
index e9fdca4..d9b2dcd 100644
--- a/drivers/staging/fsl-mc/bus/dprc-cmd.h
+++ b/drivers/staging/fsl-mc/bus/dprc-cmd.h
@@ -48,7 +48,7 @@
 #define DPRC_CMD_BASE_VERSION  1
 #define DPRC_CMD_ID_OFFSET 4
 
-#define DPRC_CMD(id)   ((id << DPRC_CMD_ID_OFFSET) | DPRC_CMD_BASE_VERSION)
+#define DPRC_CMD(id)   (((id) << DPRC_CMD_ID_OFFSET) | DPRC_CMD_BASE_VERSION)
 
 /* Command IDs */
 #define DPRC_CMDID_CLOSEDPRC_CMD(0x800)
diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c 
b/drivers/staging/fsl-mc/bus/dprc-driver.c
index d723c69..39c9a3b 100644
--- a/drivers/staging/fsl-mc/bus/dprc-driver.c
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -21,9 +21,13 @@
 
 #define FSL_MC_DPRC_DRIVER_NAME"fsl_mc_dprc"
 
-#define FSL_MC_DEVICE_MATCH(_mc_dev, _obj_desc) \
-   (strcmp((_mc_dev)->obj_desc.type, (_obj_desc)->type) == 0 && \
-(_mc_dev)->obj_desc.id == (_obj_desc)->id)
+#define FSL_MC_DEVICE_MATCH(_mc_dev, _obj_desc)
\
+({ \
+   struct fsl_mc_device *__mc_dev = _mc_dev;   \
+   struct dprc_obj_desc *__obj_desc = _obj_desc;   \
+   (strcmp(__mc_dev->obj_desc.type, __obj_desc->type) == 0 &&  \
+   __mc_dev->obj_desc.id == __obj_desc->id);   \
+})
 
 struct dprc_child_objs {
int child_count;
diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c 
b/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
index ce07096..d3def40 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
@@ -17,10 +17,13 @@
 #include "dpcon-cmd.h"
 #include "fsl-mc-private.h"
 
-#define FSL_MC_IS_ALLOCATABLE(_obj_type) \
-   (strcmp(_obj_type, "dpbp") == 0 || \
-strcmp(_obj_type, "dpmcp") == 0 || \
-strcmp(_obj_type, "dpcon") == 0)
+#define FSL_MC_IS_ALLOCATABLE(_obj_type)   \
+({ \
+   const char *__obj_type = 

[PATCH 4/5] staging: fsl-mc: add reference to mc-bus DT binding

[laurentiu.tudor]

From: Laurentiu Tudor 

Update README to reference the mc-bus device tree node
binding.

Signed-off-by: Laurentiu Tudor 
---
 drivers/staging/fsl-mc/README.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/fsl-mc/README.txt 
b/drivers/staging/fsl-mc/README.txt
index d7cd70a..524eda1 100644
--- a/drivers/staging/fsl-mc/README.txt
+++ b/drivers/staging/fsl-mc/README.txt
@@ -320,6 +320,8 @@ A brief description of each driver is provided below.
-creates an MSI IRQ domain
-doing a 'device add' to expose the 'root' DPRC, in turn triggering
 a bind of the root DPRC to the DPRC driver
+The binding for the MC-bus device-tree node can be consulted here:
+Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
 
 DPRC driver
 ---
-- 
2.9.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/5] staging: fsl-mc: drop reference to restool

[laurentiu.tudor]

From: Laurentiu Tudor 

Drop reference to user space restool utility from the README.
It will be added back together with the actual support in the
bus driver.

Signed-off-by: Laurentiu Tudor 
---
 drivers/staging/fsl-mc/README.txt | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/fsl-mc/README.txt 
b/drivers/staging/fsl-mc/README.txt
index 179536a..d7cd70a 100644
--- a/drivers/staging/fsl-mc/README.txt
+++ b/drivers/staging/fsl-mc/README.txt
@@ -131,9 +131,7 @@ in creating a network interfaces.
 
 DPRCs can be defined statically and populated with objects
 via a config file passed to the MC when firmware starts
-it.  There is also a Linux user space tool called "restool"
-that can be used to create/destroy containers and objects
-dynamically.
+it.
 
 -DPAA2 Objects for an Ethernet Network Interface
 
-- 
2.9.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/5][v2] staging: fsl-mc: add binding path to MAINTAINERS

[laurentiu.tudor]

From: Laurentiu Tudor 

Signed-off-by: Laurentiu Tudor 
---

Notes:
-v2
  -no changes

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9e98464..ffac090 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10545,6 +10545,7 @@ M:  Laurentiu Tudor 
 L: linux-ker...@vger.kernel.org
 S: Maintained
 F: drivers/staging/fsl-mc/
+F: Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
 
 QT1010 MEDIA DRIVER
 M: Antti Palosaari 
-- 
2.9.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/5][v5] staging: fsl-mc: move bus driver out of staging

[laurentiu.tudor]

From: Laurentiu Tudor 

Now that there is a functional ethernet driver probed on the
mc bus this patch series requests that the fsl-mc bus driver
be moved out of staging.

The proposed destination for the bus driver is drivers/bus.
Proposed location for global header files for fsl-mc and dpaa2
is the already existing include/linux/fsl.

First couple of patches fix several checkpatch.pl and README issues
and the last patch moves the bus out of staging, updating all
the users (e.g. #include paths).

Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git, staging-next

Link to previous version:
https://lkml.org/lkml/2017/5/19/417

Link to last round of driver model fixes & cleanups:
https://lkml.org/lkml/2017/2/1/235

version 5 changes
 - drop restool utility reference from README (Marc Zyngier)
 - add binding path in README (Marc Zyngier)

version 4 changes
 - rebased on latest staging-next
 - dpio was submitted separately so dropped from the series
 - several checkpatch.pl --strict fixes (first 2 patches)
 - update existing dpaa2 drivers to match the new fsl-mc bus location

version 3 changes
   -zero memory allocated for a dpio store
   -replace hardcoded dequeue token with a #define and look for
that token when checking for a new result

version 2 changes (mostly feedback from Ioana Radulescu)
   -removed unused structs and defines in dpio command definitions
   -added setter/getter for the FD ctrl field
   -corrected comment for SG format_offset field description
   -added support for short length field in FD
   -fix bug in buffer release command, by setting bpid field
   -handle error (NULL) return value from qbman_swp_mc_complete()
   -fix bug in sending management commands where the verb was
properly initialized
   -use service_select_by_cpu() for re-arming DPIO interrupts
   -replace use of NR_CPUS with num_possible_cpus()
   -handle error case where number of DPIOs exceeds number of possible
CPUs
   -error message cleanup
   -updated MAINTAINERS file with proper location for both fsl-mc bus
driver and dpio driver

Laurentiu Tudor (4):
  staging: fsl-mc: fix several checkpath.pl warnings
  staging: fsl-mc: add binding path to MAINTAINERS
  staging: fsl-mc: drop reference to restool
  staging: fsl-mc: add reference to mc-bus DT binding

Stuart Yoder (1):
  staging: fsl-mc: move bus driver out of staging

 .../README.txt => Documentation/dpaa2/overview.txt|  6 +++---
 MAINTAINERS   |  3 ++-
 drivers/bus/Kconfig   |  2 ++
 drivers/bus/Makefile  |  3 +++
 drivers/bus/fsl-mc/Kconfig| 17 +
 drivers/bus/fsl-mc/Makefile   | 19 +++
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h |  2 +-
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c |  6 +++---
 .../{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h|  2 +-
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c|  4 ++--
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h|  0
 .../{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h|  2 +-
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c|  6 +++---
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h |  2 +-
 .../{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c  | 14 +-
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c |  6 +++---
 .../fsl-mc/bus => bus/fsl-mc}/fsl-mc-allocator.c  | 17 ++---
 .../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-bus.c   | 18 ++
 .../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-msi.c   |  4 +++-
 .../fsl-mc/bus => bus/fsl-mc}/fsl-mc-private.h|  3 +--
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-io.c|  5 +++--
 drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-sys.c   |  6 +++---
 drivers/irqchip/Makefile  |  1 +
 .../bus => irqchip}/irq-gic-v3-its-fsl-mc-msi.c   |  3 +--
 drivers/staging/fsl-dpaa2/ethernet/README |  2 +-
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c|  4 ++--
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h|  2 +-
 drivers/staging/fsl-dpaa2/ethernet/dpni.c |  4 ++--
 drivers/staging/fsl-mc/TODO   | 18 --
 drivers/staging/fsl-mc/bus/Kconfig| 10 --
 drivers/staging/fsl-mc/bus/Makefile   | 15 +--
 drivers/staging/fsl-mc/bus/dpcon.c|  8 
 drivers/staging/fsl-mc/bus/dpio/dpio-driver.c |  2 +-
 drivers/staging/fsl-mc/bus/dpio/dpio-service.c|  2 +-
 drivers/staging/fsl-mc/bus/dpio/dpio.c|  4 ++--
 .../fsl-mc/include => include/linux/fsl}/dpbp.h   |  0
 .../fsl-mc/bus => include/linux/fsl}/dpcon-cmd.h  |  0
 .../fsl-mc/include => include/linux/fsl}/dpmng.h  |  0
 .../fsl-mc/include => include/linux/fsl}/dprc.h   

Re: [PATCH] Fixed cameCase check in file drivers/staging/sm750fb/ddk750_chip.c

[Dan Carpenter]

On Mon, May 22, 2017 at 04:15:37PM +0530, Richa Jha wrote:
> Changes :
> 
> ulActualMxClk ---> ul_actual_max_clk
> p_init_param  ---> pInitParam

It doesn't touch p_init_param.

> ---
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
> 
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> ---

These non-disclosure things aren't allowed.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Fixed cameCase check in file drivers/staging/sm750fb/ddk750_chip.c

[Richa Jha]

Changes :

ulActualMxClk ---> ul_actual_max_clk
p_init_param  ---> pInitParam

Signed-off-by: Richa Jha 
---
 drivers/staging/sm750fb/ddk750_chip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 4f646f2..00bca17 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -55,7 +55,7 @@ static unsigned int get_mxclk_freq(void)
 static void set_chip_clock(unsigned int frequency)
 {
struct pll_value pll;
-   unsigned int ul_actual_max_Clk;
+   unsigned int ul_actual_max_clk;
 
/* Cheok_0509: For SM750LE, the chip clock is fixed. Nothing to set. */
if (sm750_get_chip_type() == SM750LE)
@@ -75,7 +75,7 @@ static void set_chip_clock(unsigned int frequency)
 * Return value of sm750_calc_pll_value gives the actual
 * possible clock.
 */
-   ul_actual_max_Clk = sm750_calc_pll_value(frequency, );
+   ul_actual_max_clk = sm750_calc_pll_value(frequency, );
 
/* Master Clock Control: MXCLK_PLL */
poke32(MXCLK_PLL_CTRL, sm750_format_pll_reg());
-- 
2.1.4


---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB flush

[Vitaly Kuznetsov]

Andy Lutomirski  writes:

> On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote:
>> Hyper-V host can suggest us to use hypercall for doing remote TLB flush,
>> this is supposed to work faster than IPIs.
>>
>> Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls
>> we need to put the input somewhere in memory and we don't really want to
>> have memory allocation on each call so we pre-allocate per cpu memory areas
>> on boot. These areas are of fixes size, limit them with an arbitrary number
>> of 16 (16 gvas are able to specify 16 * 4096 pages).
>>
>> pv_ops patching is happening very early so we need to separate
>> hyperv_setup_mmu_ops() and hyper_alloc_mmu().
>>
>> It is possible and easy to implement local TLB flushing too and there is
>> even a hint for that. However, I don't see a room for optimization on the
>> host side as both hypercall and native tlb flush will result in vmexit. The
>> hint is also not set on modern Hyper-V versions.
>
> Why do local flushes exit?

"exist"? I don't know, to be honest. To me it makes no difference from
hypervisor's point of view as intercepting tlb flushing instructions is
not any different from implmenting a hypercall.

Hyper-V gives its guests 'hints' to indicate if they need to use
hypercalls for remote/locat TLB flush and I don't remember seeing
'local' bit set.

Microsoft folks may probably shed some light on why this was added.

>
>> +static void hyperv_flush_tlb_others(const struct cpumask *cpus,
>> +struct mm_struct *mm, unsigned long start,
>> +unsigned long end)
>> +{
>
> What tree will this go through?  I'm about to send a signature change
> for this function for tip:x86/mm.

I think this was going to get through Greg's char-misc tree but if we
need to synchronize I think we can push this through x86.

>
> Also, how would this interact with PCID?  I have PCID patches that I'm
> pretty happy with now, and I'm hoping to support PCID in 4.13.
>

Sorry, I wasn't following this work closely. .flush_tlb_others() hook is
not going away from pv_mmu_ops, right? In think case we can have both in
4.13. Or do you see any other clashes?

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 04/10] x86/hyper-v: fast hypercall implementation

[Vitaly Kuznetsov]

Andy Lutomirski  writes:

> On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote:
>> Hyper-V supports 'fast' hypercalls when all parameters are passed through
>> registers. Implement an inline version of a simpliest of these calls:
>> hypercall with one 8-byte input and no output.
>>
>> Proper hypercall input interface (struct hv_hypercall_input) definition is
>> added as well.
>>
>> Signed-off-by: Vitaly Kuznetsov 
>> Acked-by: K. Y. Srinivasan 
>> Tested-by: Simon Xiao 
>> Tested-by: Srikanth Myakam 
>> ---
>>   arch/x86/include/asm/mshyperv.h| 39 
>> ++
>>   arch/x86/include/uapi/asm/hyperv.h | 19 +++
>>   2 files changed, 58 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/mshyperv.h 
>> b/arch/x86/include/asm/mshyperv.h
>> index e293937..028e29b 100644
>> --- a/arch/x86/include/asm/mshyperv.h
>> +++ b/arch/x86/include/asm/mshyperv.h
>> @@ -216,6 +216,45 @@ static inline u64 hv_do_hypercall(u64 control, void 
>> *input, void *output)
>>   #endif /* !x86_64 */
>>   }
>>   +/* Fast hypercall with 8 bytes of input and no output */
>> +static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
>> +{
>> +union hv_hypercall_input control = {0};
>> +
>> +control.code = code;
>> +control.fast = 1;
>> +#ifdef CONFIG_X86_64
>> +{
>> +u64 hv_status;
>> +
>> +__asm__ __volatile__("call *%3"
>> + : "=a" (hv_status),
>> +   "+c" (control.as_uint64), "+d" (input1)
>> + : "m" (hv_hypercall_pg)
>> + : "cc", "r8", "r9", "r10", "r11");
>> +return hv_status;
>> +}
>> +#else
>> +{
>> +u32 hv_status_hi, hv_status_lo;
>> +u32 input1_hi = (u32)(input1 >> 32);
>> +u32 input1_lo = (u32)input1;
>> +
>> +__asm__ __volatile__ ("call *%6"
>> +  : "=d"(hv_status_hi),
>> +"=a"(hv_status_lo),
>> +"+c"(input1_lo)
>> +  : "d" (control.as_uint32_hi),
>> +"a" (control.as_uint32_lo),
>> +"b" (input1_hi),
>> +"m" (hv_hypercall_pg)
>> +  : "cc", "edi", "esi");
>> +
>> +return hv_status_lo | ((u64)hv_status_hi << 32);
>> +}
>> +#endif
>
> This is going to need an explicit "sp" annotation to force a stack
> frame, I think.  Otherwise objtool is likely to get mad in a
> frame-pointer-omitted build.
>

You mean I should do something like 

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 359967f..f86c4ae 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -221,6 +221,7 @@ static inline u64 hv_do_hypercall(u64 control, void *input, 
void *output)
 static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
 {
union hv_hypercall_input control = {0};
+   register void *__sp asm(_ASM_SP);
 
control.code = code;
control.fast = 1;
@@ -228,8 +229,8 @@ static inline u64 hv_do_fast_hypercall8(u16 code, u64 
input1)
{
u64 hv_status;
 
-   __asm__ __volatile__("call *%3"
-: "=a" (hv_status),
+   __asm__ __volatile__("call *%4"
+: "=a" (hv_status), "+r" (__sp),
   "+c" (control.as_uint64), "+d" (input1)
 : "m" (hv_hypercall_pg)
 : "cc", "r8", "r9", "r10", "r11");
@@ -241,10 +242,11 @@ static inline u64 hv_do_fast_hypercall8(u16 code, u64 
input1)
u32 input1_hi = (u32)(input1 >> 32);
u32 input1_lo = (u32)input1;
 
-   __asm__ __volatile__ ("call *%6"
+   __asm__ __volatile__ ("call *%7"
  : "=d"(hv_status_hi),
"=a"(hv_status_lo),
-   "+c"(input1_lo)
+   "+c"(input1_lo),
+   "+r"(__sp)
  : "d" (control.as_uint32_hi),
"a" (control.as_uint32_lo),
"b" (input1_hi),

(stollen from 0e8e2238)? hv_do_hypercall() will need this adjustment
too, I think.

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Removed CamelCase from file drivers/staging/sm750fb/ddk750_chip.c

[Richa Jha]

Changes :
devId ---> dev_id
revId ---> rev_id

Signed-off-by: Richa Jha 
---
 drivers/staging/sm750fb/ddk750_chip.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 5e4bfb6..8e51f60 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -14,14 +14,14 @@ logical_chip_type_t sm750_get_chip_type(void)
return chip;
 }
 
-void sm750_set_chip_type(unsigned short devId, u8 revId)
+void sm750_set_chip_type(unsigned short dev_id, u8 rev_id)
 {
-   if (devId == 0x718) {
+   if (dev_id == 0x718) {
chip = SM718;
-   } else if (devId == 0x750) {
+   } else if (dev_id == 0x750) {
chip = SM750;
/* SM750 and SM750LE are different in their revision ID only. */
-   if (revId == SM750LE_REVISION_ID) {
+   if (rev_id == SM750LE_REVISION_ID) {
chip = SM750LE;
pr_info("found sm750le\n");
}
-- 
2.1.4


---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] drivers/staging/speakup: fix some coding style problem in spk_ttyio.c

[Greg Kroah-Hartman]

On Sun, May 21, 2017 at 02:43:47AM +0800, Rui Teng wrote:
> This is a patch to the spk_ttyio.c file which fixes up the problems
> reported by the checkpatch.pl tool.

Be specific as to what you are fixing up please.

And don't do more than one "type" of cleanup in the same patch.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging

[Laurentiu Tudor]

> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Monday, May 22, 2017 12:06 PM
> To: Laurentiu Tudor 
> 
> On 22/05/17 09:42, Laurentiu Tudor wrote:
> > Hi Marc,
> >
> >> -Original Message-
> >> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> >> Sent: Monday, May 22, 2017 10:41 AM
> >>
> >> On Mon, May 22 2017 at  7:12:39 am GMT, Laurentiu Tudor
> >>  wrote:
> >>
> >> Hi Laurentiu,
> >>
> >>> Hi Marc,
> >>>
>  -Original Message-
>  From: Marc Zyngier [mailto:marc.zyng...@arm.com]
>  Sent: Saturday, May 20, 2017 9:43 AM
>  To: Matthias Brugger 
> 
>  On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger
>   wrote:
> > On 19/05/17 15:13, laurentiu.tu...@nxp.com wrote:
> >> From: Stuart Yoder 
> >>
> >> Move the source files out of staging into their final locations:
> >>-include files in drivers/staging/fsl-mc/include go to 
> >> include/linux/fsl
> >>-irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
> >
> > This driver has as compatible "arm,gic-v3-its". I wonder if this
> > is correct and if it should be moved like this out of staging.
> 
>  This is no different from the way we handle *any* bus that uses the
>  GICv3 ITS as an MSI controller. Each bus provides its glue code
>  that latches onto the ITS node, and calls into the generic code.
> 
>  Now, when it comes to moving this out of staging, here is my concern:
>  There is mention of a userspace tool (restool) used to control the
>  HW. Where is this tool? Where is the user ABI documented?
> >>>
> >>> The tool is published here:

[snip]

> >>> There are two ways of configuring the mc-bus:
> >>>  - a static one, through a FDT based configuration file (we call it
> >>> DPL), documented in the refman linked below, chapter 22.
> >>>  - a dynamic one, using this restool utility.
> >>> Please note the usage of restool is optional.
> >>
> >> Optional or not, it still is a userspace ABI, and while I can see
> >> restool issuing ioctl system calls to configure the HW, I cannot see
> >> the corresponding code in the kernel tree. So how does it work?
> >> If the syscall interface is not present in the mainline kernel, drop
> >> the reference to it in the documentation. If it is there (and I
> >> obviously missed it), document it, and get it reviewed.
> >
> > Our original plan was to first get the bus out of staging and after that 
> > submit
> the restool support ASAP (patches are done - so I'm thinking at few days
> timeframe).
> > if this is not acceptable, I can drop the restool reference from the README
> and resubmit the patch series. We'll re-add the reference together with the
> restool support patches.
> 
> I think it would make a lot more sense to drop anything that is not 
> implemented
> by the current code. Once you have patches that implement this userspace
> interface, they can be reviewed together with the corresponding
> documentation.

Ok, sounds good. I'll respin the patch series. 

> >> If there are associated DT bindings to the kernel code, they must be
> >> documented (and reviewed) as part of the device-tree documentation,
> >> and not in some obscure, hard to access document.
> >
> > There's only one binding involved and it's already accepted [1].
> 
> Ah, I missed it. It would be good to mention it in the documentation as well.

Good point. I'll add a reference in the next respin.

> > [snip]
> >
> >>>
> >>> We're also working on publishing the docs on github so that they're
> >>> more accessible.
> >>
> >> That'd be great, because the way the registration process is
> >> presented, I'd have to agree to the Access Agreement *before* having
> >> a chance to read it. Not going to happen...
> >
> > Sorry about that. Not much I can do. :-(
> 
> I understand this is not your job ;-). But maybe making people inside NXP 
> aware
> of the issue would help... Oh well.

I'll make sure your comments will reach our guys and in the meantime push to 
get the docs on github.

---
Thanks & Best Regards, Laurentiu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging

[Marc Zyngier]

On 22/05/17 09:42, Laurentiu Tudor wrote:
> Hi Marc,
> 
>> -Original Message-
>> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
>> Sent: Monday, May 22, 2017 10:41 AM
>>
>> On Mon, May 22 2017 at  7:12:39 am GMT, Laurentiu Tudor
>>  wrote:
>>
>> Hi Laurentiu,
>>
>>> Hi Marc,
>>>
 -Original Message-
 From: Marc Zyngier [mailto:marc.zyng...@arm.com]
 Sent: Saturday, May 20, 2017 9:43 AM
 To: Matthias Brugger 

 On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger
  wrote:
> On 19/05/17 15:13, laurentiu.tu...@nxp.com wrote:
>> From: Stuart Yoder 
>>
>> Move the source files out of staging into their final locations:
>>-include files in drivers/staging/fsl-mc/include go to 
>> include/linux/fsl
>>-irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
>
> This driver has as compatible "arm,gic-v3-its". I wonder if this is
> correct and if it should be moved like this out of staging.

 This is no different from the way we handle *any* bus that uses the
 GICv3 ITS as an MSI controller. Each bus provides its glue code that
 latches onto the ITS node, and calls into the generic code.

 Now, when it comes to moving this out of staging, here is my concern:
 There is mention of a userspace tool (restool) used to control the
 HW. Where is this tool? Where is the user ABI documented?
>>>
>>> The tool is published here:
>>>
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>> hub.com%2Fqoriq-open-
>> source%2Frestool=01%7C01%7Claurentiu.tudor%4
>>>
>> 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92
>> cd99c
>>>
>> 5c301635%7C0=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg
>> %3D
>>> served=0
>>>
>>> There are two ways of configuring the mc-bus:
>>>  - a static one, through a FDT based configuration file (we call it
>>> DPL), documented in the refman linked below, chapter 22.
>>>  - a dynamic one, using this restool utility.
>>> Please note the usage of restool is optional.
>>
>> Optional or not, it still is a userspace ABI, and while I can see restool 
>> issuing ioctl
>> system calls to configure the HW, I cannot see the corresponding code in the
>> kernel tree. So how does it work?
>> If the syscall interface is not present in the mainline kernel, drop the 
>> reference
>> to it in the documentation. If it is there (and I obviously missed it), 
>> document it,
>> and get it reviewed. 
> 
> Our original plan was to first get the bus out of staging and after that 
> submit the restool support ASAP (patches are done - so I'm thinking at few 
> days timeframe).
> if this is not acceptable, I can drop the restool reference from the README 
> and resubmit the patch series. We'll re-add the reference together with the 
> restool support patches.

I think it would make a lot more sense to drop anything that is not
implemented by the current code. Once you have patches that implement
this userspace interface, they can be reviewed together with the
corresponding documentation.

>> If there are associated DT bindings to the kernel code, they
>> must be documented (and reviewed) as part of the device-tree documentation,
>> and not in some obscure, hard to access document.
> 
> There's only one binding involved and it's already accepted [1].

Ah, I missed it. It would be good to mention it in the documentation as
well.

> [snip]
> 
>>>
>>> We're also working on publishing the docs on github so that they're
>>> more accessible.
>>
>> That'd be great, because the way the registration process is presented, I'd 
>> have
>> to agree to the Access Agreement *before* having a chance to read it. Not
>> going to happen...
> 
> Sorry about that. Not much I can do. :-( 

I understand this is not your job ;-). But maybe making people inside
NXP aware of the issue would help... Oh well.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging

[Laurentiu Tudor]

Hi Marc,

> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Monday, May 22, 2017 10:41 AM
> 
> On Mon, May 22 2017 at  7:12:39 am GMT, Laurentiu Tudor
>  wrote:
> 
> Hi Laurentiu,
> 
> > Hi Marc,
> >
> >> -Original Message-
> >> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> >> Sent: Saturday, May 20, 2017 9:43 AM
> >> To: Matthias Brugger 
> >>
> >> On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger
> >>  wrote:
> >> > On 19/05/17 15:13, laurentiu.tu...@nxp.com wrote:
> >> >> From: Stuart Yoder 
> >> >>
> >> >> Move the source files out of staging into their final locations:
> >> >>-include files in drivers/staging/fsl-mc/include go to 
> >> >> include/linux/fsl
> >> >>-irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
> >> >
> >> > This driver has as compatible "arm,gic-v3-its". I wonder if this is
> >> > correct and if it should be moved like this out of staging.
> >>
> >> This is no different from the way we handle *any* bus that uses the
> >> GICv3 ITS as an MSI controller. Each bus provides its glue code that
> >> latches onto the ITS node, and calls into the generic code.
> >>
> >> Now, when it comes to moving this out of staging, here is my concern:
> >> There is mention of a userspace tool (restool) used to control the
> >> HW. Where is this tool? Where is the user ABI documented?
> >
> > The tool is published here:
> >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fqoriq-open-
> source%2Frestool=01%7C01%7Claurentiu.tudor%4
> >
> 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92
> cd99c
> >
> 5c301635%7C0=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg
> %3D
> > served=0
> >
> > There are two ways of configuring the mc-bus:
> >  - a static one, through a FDT based configuration file (we call it
> > DPL), documented in the refman linked below, chapter 22.
> >  - a dynamic one, using this restool utility.
> > Please note the usage of restool is optional.
> 
> Optional or not, it still is a userspace ABI, and while I can see restool 
> issuing ioctl
> system calls to configure the HW, I cannot see the corresponding code in the
> kernel tree. So how does it work?
> If the syscall interface is not present in the mainline kernel, drop the 
> reference
> to it in the documentation. If it is there (and I obviously missed it), 
> document it,
> and get it reviewed. 

Our original plan was to first get the bus out of staging and after that submit 
the restool support ASAP (patches are done - so I'm thinking at few days 
timeframe).
if this is not acceptable, I can drop the restool reference from the README and 
resubmit the patch series. We'll re-add the reference together with the restool 
support patches.

> If there are associated DT bindings to the kernel code, they
> must be documented (and reviewed) as part of the device-tree documentation,
> and not in some obscure, hard to access document.

There's only one binding involved and it's already accepted [1].

[snip]

> >
> > We're also working on publishing the docs on github so that they're
> > more accessible.
> 
> That'd be great, because the way the registration process is presented, I'd 
> have
> to agree to the Access Agreement *before* having a chance to read it. Not
> going to happen...

Sorry about that. Not much I can do. :-( 

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt

---
Best Regards, Laurentiu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging

[Marc Zyngier]

On Mon, May 22 2017 at  7:12:39 am GMT, Laurentiu Tudor 
 wrote:

Hi Laurentiu,

> Hi Marc,
>
>> -Original Message-
>> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
>> Sent: Saturday, May 20, 2017 9:43 AM
>> To: Matthias Brugger 
>> Cc: Laurentiu Tudor ; gre...@linuxfoundation.org;
>> stuyo...@gmail.com; de...@driverdev.osuosl.org; a...@arndb.de; Ruxandra
>> Ioana Radulescu ; Stuart Yoder
>> ; Roy Pledge ; linux-
>> ker...@vger.kernel.org; ag...@suse.de; Catalin Horghidan
>> ; Ioana Ciornei ;
>> Thomas Gleixner ; Leo Li ; Bharat
>> Bhushan ; Jason Cooper ;
>> linux-arm-ker...@lists.infradead.org; Rob Herring 
>> Subject: Re: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging
>> Importance: High
>> 
>> On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger
>>  wrote:
>> > On 19/05/17 15:13, laurentiu.tu...@nxp.com wrote:
>> >> From: Stuart Yoder 
>> >>
>> >> Move the source files out of staging into their final locations:
>> >>-include files in drivers/staging/fsl-mc/include go to 
>> >> include/linux/fsl
>> >>-irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
>> >
>> > This driver has as compatible "arm,gic-v3-its". I wonder if this is
>> > correct and if it should be moved like this out of staging.
>> 
>> This is no different from the way we handle *any* bus that uses the
>> GICv3 ITS as an MSI controller. Each bus provides its glue code that
>> latches onto
>> the ITS node, and calls into the generic code.
>> 
>> Now, when it comes to moving this out of staging, here is my concern:
>> There is mention of a userspace tool (restool) used to control the
>> HW. Where is
>> this tool? Where is the user ABI documented?
>
> The tool is published here:
>
> https://github.com/qoriq-open-source/restool
>
> There are two ways of configuring the mc-bus:
>  - a static one, through a FDT based configuration file (we call it
> DPL), documented in the refman linked below, chapter 22.
>  - a dynamic one, using this restool utility.
> Please note the usage of restool is optional.

Optional or not, it still is a userspace ABI, and while I can see
restool issuing ioctl system calls to configure the HW, I cannot see the
corresponding code in the kernel tree. So how does it work?

If the syscall interface is not present in the mainline kernel, drop the
reference to it in the documentation. If it is there (and I obviously
missed it), document it, and get it reviewed. If there are associated DT
bindings to the kernel code, they must be documented (and reviewed) as
part of the device-tree documentation, and not in some obscure, hard to
access document.

>
> The reference manual documenting the ABI can be found here
> (registration required):
>
> https://freescale.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-53BEBDD8-1A5E-4DD0-8354-A9647AD35755
>
> Click on the DPAA2 user manual link.
>
> We're also working on publishing the docs on github so that they're
> more accessible.

That'd be great, because the way the registration process is presented,
I'd have to agree to the Access Agreement *before* having a chance to
read it. Not going to happen...

Thanks,

M.
-- 
Jazz is not dead, it just smell funny.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging

[Laurentiu Tudor]

Hi Marc,

> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Saturday, May 20, 2017 9:43 AM
> To: Matthias Brugger 
> Cc: Laurentiu Tudor ; gre...@linuxfoundation.org;
> stuyo...@gmail.com; de...@driverdev.osuosl.org; a...@arndb.de; Ruxandra
> Ioana Radulescu ; Stuart Yoder
> ; Roy Pledge ; linux-
> ker...@vger.kernel.org; ag...@suse.de; Catalin Horghidan
> ; Ioana Ciornei ;
> Thomas Gleixner ; Leo Li ; Bharat
> Bhushan ; Jason Cooper ;
> linux-arm-ker...@lists.infradead.org; Rob Herring 
> Subject: Re: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging
> Importance: High
> 
> On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger
>  wrote:
> > On 19/05/17 15:13, laurentiu.tu...@nxp.com wrote:
> >> From: Stuart Yoder 
> >>
> >> Move the source files out of staging into their final locations:
> >>-include files in drivers/staging/fsl-mc/include go to include/linux/fsl
> >>-irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
> >
> > This driver has as compatible "arm,gic-v3-its". I wonder if this is
> > correct and if it should be moved like this out of staging.
> 
> This is no different from the way we handle *any* bus that uses the
> GICv3 ITS as an MSI controller. Each bus provides its glue code that latches 
> onto
> the ITS node, and calls into the generic code.
> 
> Now, when it comes to moving this out of staging, here is my concern:
> There is mention of a userspace tool (restool) used to control the HW. Where 
> is
> this tool? Where is the user ABI documented?

The tool is published here:

https://github.com/qoriq-open-source/restool

There are two ways of configuring the mc-bus:
 - a static one, through a FDT based configuration file (we call it DPL), 
documented in the refman linked below, chapter 22.
 - a dynamic one, using this restool utility.
Please note the usage of restool is optional.

The reference manual documenting the ABI can be found here (registration 
required):

https://freescale.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-53BEBDD8-1A5E-4DD0-8354-A9647AD35755

Click on the DPAA2 user manual link.

We're also working on publishing the docs on github so that they're more 
accessible.

---
Thanks & Best Regards, Laurentiu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel