[PATCH] Staging: wilc1000: Use NULL instead of zero

[Ronit Halder]

This patch fixes the warning generated by sparse
"Using plain integer as NULL pointer" by using NULL
instead of zero.

Signed-off-by: Ronit halder 
---
 drivers/staging/wilc1000/coreconfigurator.c | 14 +++---
 drivers/staging/wilc1000/linux_wlan.c   |  6 +++---
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
b/drivers/staging/wilc1000/coreconfigurator.c
index 544c12d..8164a33 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -525,7 +525,7 @@ u8 *get_tim_elm(u8 *pu8msa, u16 u16RxLen, u16 
u16TagParamOffset)
u16index += (IE_HDR_LEN + pu8msa[u16index + 1]);
}
 
-   return 0;
+   return NULL;
 }
 
 /* This function gets the current channel information from
@@ -587,7 +587,7 @@ s32 ParseNetworkInfo(u8 *pu8MsgBuffer, tstrNetworkInfo 
**ppstrNetworkInfo)
 
u16 u16WidID = (u16)WID_NIL;
u16 u16WidLen  = 0;
-   u8  *pu8WidVal = 0;
+   u8  *pu8WidVal = NULL;
 
u8MsgType = pu8MsgBuffer[0];
 
@@ -614,10 +614,10 @@ s32 ParseNetworkInfo(u8 *pu8MsgBuffer, tstrNetworkInfo 
**ppstrNetworkInfo)
 
/* parse the WID value of the WID "WID_NEWORK_INFO" */
{
-   u8  *pu8msa = 0;
+   u8  *pu8msa = NULL;
u16 u16RxLen = 0;
-   u8 *pu8TimElm = 0;
-   u8 *pu8IEs = 0;
+   u8 *pu8TimElm = NULL;
+   u8 *pu8IEs = NULL;
u16 u16IEsLen = 0;
u8 u8index = 0;
u32 u32Tsf_Lo;
@@ -670,7 +670,7 @@ s32 ParseNetworkInfo(u8 *pu8MsgBuffer, tstrNetworkInfo 
**ppstrNetworkInfo)
 
/* Get DTIM Period */
pu8TimElm = get_tim_elm(pu8msa, (u16RxLen + FCS_LEN), u8index);
-   if (pu8TimElm != 0)
+   if (pu8TimElm != NULL)
pstrNetworkInfo->u8DtimPeriod = pu8TimElm[3];
pu8IEs = [MAC_HDR_LEN + TIME_STAMP_LEN + 
BEACON_INTERVAL_LEN + CAP_INFO_LEN];
u16IEsLen = u16RxLen - (MAC_HDR_LEN + TIME_STAMP_LEN + 
BEACON_INTERVAL_LEN + CAP_INFO_LEN);
@@ -743,7 +743,7 @@ s32 ParseAssocRespInfo(u8 *pu8Buffer, u32 u32BufferLen,
s32 s32Error = WILC_SUCCESS;
tstrConnectRespInfo *pstrConnectRespInfo = NULL;
u16 u16AssocRespLen = 0;
-   u8 *pu8IEs = 0;
+   u8 *pu8IEs = NULL;
u16 u16IEsLen = 0;
 
pstrConnectRespInfo = kmalloc(sizeof(tstrConnectRespInfo), GFP_KERNEL);
diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 63f44f8..d8f17c6 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -412,7 +412,7 @@ static int isr_bh_routine(void *vp)
break;
}
PRINT_D(INT_DBG, "Interrupt received BH\n");
-   if (g_linux_wlan->oup.wlan_handle_rx_isr != 0)
+   if (g_linux_wlan->oup.wlan_handle_rx_isr != NULL)
g_linux_wlan->oup.wlan_handle_rx_isr();
else
PRINT_ER("wlan_handle_rx_isr() hasn't been 
initialized\n");
@@ -1284,7 +1284,7 @@ int wlan_initialize_threads(perInterface_wlan_t *nic)
 #elif (RX_BH_TYPE == RX_BH_KTHREAD)
PRINT_D(INIT_DBG, "Creating kthread for Rxq BH\n");
g_linux_wlan->rx_bh_thread = kthread_run(isr_bh_routine, (void 
*)g_linux_wlan, "K_RXQ_BH");
-   if (g_linux_wlan->rx_bh_thread == 0) {
+   if (g_linux_wlan->rx_bh_thread == NULL) {
PRINT_ER("couldn't create RX BH thread\n");
ret = -ENOBUFS;
goto _fail_;
@@ -1309,7 +1309,7 @@ int wlan_initialize_threads(perInterface_wlan_t *nic)
/* create tx task */
PRINT_D(INIT_DBG, "Creating kthread for transmission\n");
g_linux_wlan->txq_thread = kthread_run(linux_wlan_txq_task, (void 
*)g_linux_wlan, "K_TXQ_TASK");
-   if (g_linux_wlan->txq_thread == 0) {
+   if (g_linux_wlan->txq_thread == NULL) {
PRINT_ER("couldn't create TXQ thread\n");
ret = -ENOBUFS;
goto _fail_2;
-- 
2.4.0.GIT

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH-v5 RESEND 3/5] i2c: pxa: Add support for pxa910/988 & new configuration features

[Vaibhav Hiremath]

On Saturday 12 September 2015 12:36 AM, Wolfram Sang wrote:

On Mon, Aug 24, 2015 at 11:29:36AM +0530, Vaibhav Hiremath wrote:

TWSI_ILCR & TWSI_IWCR registers are used to adjust clock rate
of standard & fast mode in pxa910/988; so this patch adds these two new
entries to "struct pxa_reg_layout" and "struct pxa_i2c".

As discussed in the previous patch-series, the idea here is to add standard
DT properties for ilcr and iwcr configuration fields.
In case of Master ilcr is used for low/high time and in case of slave mode
of operation iwcr is used for setup/hold time.


I need to rethink how to describe i2c bus timing parameters in DT in the
next days. But this is planned for 4.4., promised.

One thing I already wonder about this one...


  static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa2xx-i2c",   REGS_PXA2XX },
{ "pxa3xx-pwri2c",REGS_PXA3XX },
{ "ce4100-i2c",   REGS_CE4100 },
+   { "pxa910-i2c",   REGS_PXA910 },
{ },


You add a new platform_id...


@@ -1135,7 +1170,7 @@ static const struct i2c_algorithm i2c_pxa_pio_algorithm = 
{
  static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
-   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA2XX },
+   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
{}


...but change the compatible binding instead of adding a new one?



Yes, because the offset for both REGS_PXA2XX and REGS_PXA910 are same,
and for REGS_PXA2XX we already have compatible entry "mrvl,pxa-i2c".
And the i2c binding documentation, which says,
for platforms using REGS_PXA2XX, they need to provide additional node
"mrvl,pxa-i2c". Which is confusing :)

Also, when I did git-blame on the driver file to see why "mmp-twsi"
entry has been added without anyone really using it. But I did not find
anything meaningful.
So, from the code it was very clear that, "mmp-twsi" and "pxa-i2c" both
are same, its the code which I am adding here brings difference between 
them.


I tried to find datasheet for the platforms using "mmp-twsi", but was
unlucky.


Thanks,
Vaibhav




Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Build regressions/improvements in v4.3-rc1

[Michael Ellerman]

On Sun, 2015-09-13 at 22:23 +0200, Geert Uytterhoeven wrote:
> On Sun, Sep 13, 2015 at 5:19 PM, Guenter Roeck  wrote:
> > arm64:allmodconfig:
> >
> > drivers/firmware/qcom_scm-32.c:196:4: error: expected string literal before 
> > ‘__asmeq’
> > drivers/firmware/qcom_scm-32.c:221:2: error: implicit declaration of 
> > function ‘secure_flush_area’
> > drivers/firmware/qcom_scm-32.c:239:2: error: implicit declaration of 
> > function ‘outer_inv_range’
> > drivers/firmware/qcom_scm-32.c:331:4: error: expected string literal before 
> > ‘__asmeq’
> > drivers/firmware/qcom_scm-32.c:361:4: error: expected string literal before 
> > ‘__asmeq’
> 
> Time for kisskb to gain arm64 support?

Yes. I'll add it to my TODO list.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] cpufreq : powernv: Report Pmax throttling if capped below nominal frequency

[Shilpasri G Bhat]

Log a 'critical' message if the max frequency is reduced below nominal
frequency. We already log 'info' message if the max frequency is
capped below turbo frequency. CPU should guarantee atleast nominal
frequency, but not turbo frequency in all system configurations and
environments. So report the pmax throttling with severity when Pmax is
dipped below nominal frequency.

Signed-off-by: Shilpasri G Bhat 
---
 drivers/cpufreq/powernv-cpufreq.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index 64994e1..2d9ed42 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -327,8 +327,13 @@ static void powernv_cpufreq_throttle_check(void *data)
if (chips[i].throttled)
goto next;
chips[i].throttled = true;
-   pr_info("CPU %d on Chip %u has Pmax reduced to %d\n", cpu,
-   chips[i].id, pmsr_pmax);
+   if (pmsr_pmax < powernv_pstate_info.nominal)
+   pr_crit("CPU %d on Chip %u has Pmax reduced to %d\n",
+   cpu, chips[i].id, pmsr_pmax);
+   else
+   pr_info("CPU %d on Chip %u has Pmax reduced to %d\n",
+   cpu, chips[i].id, pmsr_pmax);
+
} else if (chips[i].throttled) {
chips[i].throttled = false;
pr_info("CPU %d on Chip %u has Pmax restored to %d\n", cpu,
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH-v5 RESEND 2/5] i2c: pxa: enable/disable i2c module across msg xfer

[Vaibhav Hiremath]

On Saturday 12 September 2015 12:23 AM, Wolfram Sang wrote:

On Mon, Aug 24, 2015 at 11:29:35AM +0530, Vaibhav Hiremath wrote:

From: Yi Zhang 

Enable i2c module/unit before transmission and disable when it
finishes.

why?
It's because the i2c bus may be disturbed if the slave device,
typically a touch, powers on.


I am not convinced, "may disturb" is too weak for me. It would need a
way more detailed description of the problem which makes clear that
this mechanism is the only way to go forward.



Hmm, Ok.
Not sure what else I can bring up here.


Can't you use Runtime PM for that?



I haven't tried it though, I can give a try and check.

Thanks,
Vaibhav

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: dgnc: Fixed line over 80 characters long

[Greg KH]

On Sun, Sep 13, 2015 at 04:22:00PM +0530, Anjali Menon wrote:
> This is a patch that fixes line over 80 characters coding style
> warning detected by checkpatch.pl.
> 
> WARNING: line over 80 characters
> 
> Signed-off-by: Anjali Menon 
> ---
>  drivers/staging/dgnc/dgnc_mgmt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/dgnc/dgnc_mgmt.c 
> b/drivers/staging/dgnc/dgnc_mgmt.c
> index b13318a..81c793a 100644
> --- a/drivers/staging/dgnc/dgnc_mgmt.c
> +++ b/drivers/staging/dgnc/dgnc_mgmt.c
> @@ -148,7 +148,8 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, 
> unsigned long arg)
>   di.info_bdstate = dgnc_Board[brd]->dpastatus;
>   di.info_ioport = 0;
>   di.info_physaddr = (ulong) dgnc_Board[brd]->membase;
> - di.info_physsize = (ulong) dgnc_Board[brd]->membase - 
> dgnc_Board[brd]->membase_end;
> + di.info_physsize = (ulong) dgnc_Board[brd]->membase
> + - dgnc_Board[brd]->membase_end;

This looks worse than it did before, there's better ways to make this
line shorter.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: wilc1000: Added a new line

[Greg KH]

On Sun, Sep 13, 2015 at 04:31:33PM +0530, Aparna Karuthodi wrote:
> Added a new line after declaration to remove a coding style warning
> detected by checkpatch. The warning is given below
> WARNING: Missing a blank line after declarations
> 
> Signed-off-by: Aparna Karuthodi 
> ---
>  drivers/staging/wilc1000/coreconfigurator.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
> b/drivers/staging/wilc1000/coreconfigurator.c
> index ed6ac45..0c964c6 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.c
> +++ b/drivers/staging/wilc1000/coreconfigurator.c
> @@ -2101,6 +2101,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
> u32 u32WIDsCount, bool bRespRequired, u32 drvHandler)
>  {
>   s32 counter = 0, ret = 0;
> +
>   if (gpstrWlanOps == NULL) {
>   PRINT_D(CORECONFIG_DBG, "Net Dev is still not initialized\n");
>   return 1;

someone already sent in this change before you did, sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivers: staging: wilc1000 - NULL pointer dereference

[Greg KH]

On Sun, Sep 13, 2015 at 06:17:26PM +0530, Chandra Gorentla wrote:
> Hi,
> 
> At this point I do not have the hardware.
> 
> NULL pointer deference is observed in the wilc1000.ko module on x86 target
> with bus type SPI and when SPI is not ready.  Following are the steps to
> reproduce.
> 
> $ sudo insmod drivers/staging/wilc1000/wilc1000.ko
> $ sudo ifconfig wlan1 up
> 
> wlan1 in the above command is the device controlled by 'wilc1000.ko'.
> 
> Though the target I tested is not built to support WILC1000, my test
> scenario can be treated as a case where in SPI is not working or WILC1000
> is not connected to the supported hardware.
> 
> I think I know a fix (pasted below) to this but cannot test it because 
> hardware
> is not available to test positive cases.
> 
> Thanks,
> chandra
> 
> gcs@gcs-HP-Compaq-nx6320:~/linux/staging$ git diff
> diff --git a/drivers/staging/wilc1000/linux_wlan.c 
> b/drivers/staging/wilc1000/linux_wlan.c
> index 63f44f8..48f063d 100644
> --- a/drivers/staging/wilc1000/linux_wlan.c
> +++ b/drivers/staging/wilc1000/linux_wlan.c
> @@ -1634,6 +1634,12 @@ int mac_open(struct net_device *ndev)
>   int i = 0;
>   struct WILC_WFI_priv *priv;
>  
> +#ifdef WILC_SPI
> + if (!g_linux_wlan || !g_linux_wlan->wilc_spidev) {
> + netdev_err(ndev, "wilc1000: SPI device not ready\n");
> + return -ENODEV;
> + }
> +#endif
>   nic = netdev_priv(ndev);
>   priv = wiphy_priv(nic->wilc_netdev->ieee80211_ptr->wiphy);
>   PRINT_D(INIT_DBG, "MAC OPEN[%p]\n", ndev);
> gcs@gcs-HP-Compaq-nx6320:~/linux/staging$ 
> 

Can you resend this in a format that I can apply it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the kdbus tree with Linus' tree

[Greg KH]

On Mon, Sep 14, 2015 at 10:53:56AM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the kdbus tree got a conflict in:
> 
>   tools/testing/selftests/Makefile
> 
> between commit:
> 
>   b6d973441675 ("selftests: add membarrier syscall test")
> 
> from Linus' tree and commit:
> 
>   b7270dd9f7d4 ("kdbus: add selftests")
> 
> from the kdbus tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc tools/testing/selftests/Makefile
> index 89b05ec9,b57100cefb74..
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@@ -4,9 -4,8 +4,10 @@@ TARGETS += efivarf
>   TARGETS += exec
>   TARGETS += firmware
>   TARGETS += ftrace
>  +TARGETS += futex
>   TARGETS += kcmp
> + TARGETS += kdbus
>  +TARGETS += membarrier
>   TARGETS += memfd
>   TARGETS += memory-hotplug
>   TARGETS += mount

Looks good to me, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver

[Pratyush Anand]

On 10/09/2015:06:45:17 PM, Jon Masters wrote:
> On 06/03/2015 02:53 PM, Timur Tabi wrote:
> > On 06/03/2015 01:25 PM, Guenter Roeck wrote:
> >> In general the idea here would be to use a crashdump kernel, which,
> >> when loaded, would reset the watchdog before it fires. This kernel
> >> would then write a core dump to a specified location.

And this is what we do in fedora or RHEL. There had been some work ongoing in
fedora [1][2] which will help to reset any active watchdog in kdump kernel(if
the watchdog driver has been registered to watchdog_class). It will eventually
help a watchdog on ARM64 platform as well.

[1] https://lists.fedoraproject.org/pipermail/kexec/2015-September/002295.html
[2] https://github.com/pratyushanand/kexec-tools/commits/watchdog_fmaster

~Pratyush
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/3] devicetree: macb: Add optional property tsu-clk

[Harini Katakam]

On Fri, Sep 11, 2015 at 10:22 PM, Sören Brinkmann
 wrote:
> Hi Harini,
>
> On Fri, 2015-09-11 at 01:27PM +0530, Harini Katakam wrote:
>> Add TSU clock frequency to be used for 1588 support in macb driver.
>>
>> Signed-off-by: Harini Katakam 
>> ---
>>  Documentation/devicetree/bindings/net/macb.txt |3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/macb.txt 
>> b/Documentation/devicetree/bindings/net/macb.txt
>> index b5d7976..f7c0ea8 100644
>> --- a/Documentation/devicetree/bindings/net/macb.txt
>> +++ b/Documentation/devicetree/bindings/net/macb.txt
>> @@ -19,6 +19,9 @@ Required properties:
>>   Optional elements: 'tx_clk'
>>  - clocks: Phandles to input clocks.
>>
>> +Optional properties:
>> +- tsu-clk: Time stamp unit clock frequency used.
>
> Why are we not using the CCF and a clk_get_rate() in the driver?
>

If the clock source was only internal, we could use this
approach as usual. But TSU clock can be configured to
come from an external clock source or internal.

Regards,
Harini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] Thermal-SoC management updates for v4.3-rc2

[Eduardo Valentin]

Hello Rui,

(apologize for duplicates, now copying the mailing lists)

Please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes

to receive Thermal-SoC Management updates for v4.3-rc2 with top-most

eba4f88d5af84e0fcaa5d6eb4fe35a75c47203cb:

  thermal: cpu_cooling: free power table on error or when unregistering 
(2015-09-13 20:34:05 -0700)

on top of commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

Specifics:
- Add compile test flags on thermal drivers that allow it without
producing compilation errors
- Fixes around memory allocation on cpu_cooling
- Fix on db8500 cpufreq code to allow autoload
- Maintainer entries for cpu cooling device

More fixes still to come, but if not for rc2, for rc3.

BR,

Eduardo Valentin

Eduardo Valentin (10):
  thermal: hisi: allow compile test
  thermal: spear: allow compile test
  thermal: rockchip: allow compile test
  thermal: kirkwood: allow compile test
  thermal: dove: allow compile test
  thermal: armada: allow compile test
  thermal: exynos: allow compile test
  thermal: qcom_spmi: allow compile test
  thermal: ti-soc: allow compile test
  thermal: ti-soc: Kconfig fix to avoid menu showing wrongly

Javi Merino (2):
  thermal: cpu_cooling: don't call kcalloc() under rcu_read_lock
  thermal: cpu_cooling: free power table on error or when unregistering

Luis de Bethencourt (1):
  thermal: db8500_cpufreq_cooling: Fix module autoload for OF platform 
driver

Punit Agrawal (1):
  thermal: Fix thermal_zone_of_sensor_register to match documentation

Viresh Kumar (1):
  thermal: cpu_cooling: Add MAINTAINERS entry

 MAINTAINERS  | 10 ++
 drivers/thermal/Kconfig  | 17 ++-
 drivers/thermal/cpu_cooling.c| 52 +++-
 drivers/thermal/db8500_cpufreq_cooling.c |  1 +
 drivers/thermal/ti-soc-thermal/Kconfig   |  8 ++---
 include/linux/thermal.h  |  2 +-
 6 files changed, 55 insertions(+), 35 deletions(-)


signature.asc
Description: Digital signature

Re: [PATCH 02/39] nilfs2: drop null test before destroy functions

[Ryusuke Konishi]

On Sun, 13 Sep 2015 14:14:55 +0200, Julia Lawall  wrote:
> Remove unneeded NULL test.
> 
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // 
> @@ expression x; @@
> -if (x != NULL)
>   \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
> // 
> 
> Signed-off-by: Julia Lawall 

Looks OK.  I'll queue this in my tree.

Thanks,
Ryusuke Konishi

> 
> ---
>  fs/nilfs2/super.c |   12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/nilfs2/super.c b/fs/nilfs2/super.c
> index f47585b..c69455a 100644
> --- a/fs/nilfs2/super.c
> +++ b/fs/nilfs2/super.c
> @@ -1405,14 +1405,10 @@ static void nilfs_destroy_cachep(void)
>*/
>   rcu_barrier();
>  
> - if (nilfs_inode_cachep)
> - kmem_cache_destroy(nilfs_inode_cachep);
> - if (nilfs_transaction_cachep)
> - kmem_cache_destroy(nilfs_transaction_cachep);
> - if (nilfs_segbuf_cachep)
> - kmem_cache_destroy(nilfs_segbuf_cachep);
> - if (nilfs_btree_path_cache)
> - kmem_cache_destroy(nilfs_btree_path_cache);
> + kmem_cache_destroy(nilfs_inode_cachep);
> + kmem_cache_destroy(nilfs_transaction_cachep);
> + kmem_cache_destroy(nilfs_segbuf_cachep);
> + kmem_cache_destroy(nilfs_btree_path_cache);
>  }
>  
>  static int __init nilfs_init_cachep(void)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 0/4] iio: new chemical sensor framework and channel types

[Matt Ranostay]

Changes from v4:
* Add IIO_MOD_CO2 and IIO_MOD_VOC modifiers
* Updated IIO_RESISTANCE and IIO_CONCENTRATION documentation
* Moved the decimal point shifting to the scale value versus the reading

Matt Ranostay (4):
  iio: chemical: Add IIO_CONCENTRATION channel type
  iio: resistance: add IIO_RESISTANCE channel type
  devicetree: add SGX Sensortech vendor id
  iio: chemical: add SGX VZ89x VOC sensor support

 Documentation/ABI/testing/sysfs-bus-iio|  19 ++
 .../ABI/testing/sysfs-bus-iio-chemical-vz89x   |   7 +
 .../devicetree/bindings/i2c/trivial-devices.txt|   1 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/iio/Kconfig|   1 +
 drivers/iio/Makefile   |   1 +
 drivers/iio/chemical/Kconfig   |  15 ++
 drivers/iio/chemical/Makefile  |   6 +
 drivers/iio/chemical/vz89x.c   | 237 +
 drivers/iio/industrialio-core.c|   4 +
 include/uapi/linux/iio/types.h |   4 +
 11 files changed, 296 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x
 create mode 100644 drivers/iio/chemical/Kconfig
 create mode 100644 drivers/iio/chemical/Makefile
 create mode 100644 drivers/iio/chemical/vz89x.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 4/4] iio: chemical: add SGX VZ89x VOC sensor support

[Matt Ranostay]

Add support for VZ89X sensors VOC and CO2 reporting channels in
percentage which can be converted to part per million.

Signed-off-by: Matt Ranostay 
---
 .../ABI/testing/sysfs-bus-iio-chemical-vz89x   |   7 +
 .../devicetree/bindings/i2c/trivial-devices.txt|   1 +
 drivers/iio/Kconfig|   1 +
 drivers/iio/Makefile   |   1 +
 drivers/iio/chemical/Kconfig   |  15 ++
 drivers/iio/chemical/Makefile  |   6 +
 drivers/iio/chemical/vz89x.c   | 237 +
 7 files changed, 268 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x
 create mode 100644 drivers/iio/chemical/Kconfig
 create mode 100644 drivers/iio/chemical/Makefile
 create mode 100644 drivers/iio/chemical/vz89x.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x 
b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x
new file mode 100644
index 000..c0c1ea9
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x
@@ -0,0 +1,7 @@
+What:  /sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw
+Date:  September 2015
+KernelVersion: 4.3
+Contact:   Matt Ranostay 
+Description:
+   Get the raw calibration VOC value from the sensor.
+   This value has little application outside of calibration.
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index d77d412..a550216 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -88,6 +88,7 @@ ricoh,rs5c372bI2C bus SERIAL INTERFACE 
REAL-TIME CLOCK IC
 ricoh,rv5c386  I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
 ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
 samsung,24ad0xd1   S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
+sgx,vz89x  SGX Sensortech VZ89X Sensors
 sii,s35390a2-wire CMOS real-time clock
 skyworks,sky81452  Skyworks SKY81452: Six-Channel White LED Driver with 
Touch Panel Bias Supply
 st-micro,24c256i2c serial eeprom  (24cxx)
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..9664e9c 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -61,6 +61,7 @@ config IIO_CONSUMERS_PER_TRIGGER
 source "drivers/iio/accel/Kconfig"
 source "drivers/iio/adc/Kconfig"
 source "drivers/iio/amplifiers/Kconfig"
+source "drivers/iio/chemical/Kconfig"
 source "drivers/iio/common/Kconfig"
 source "drivers/iio/dac/Kconfig"
 source "drivers/iio/frequency/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..2288684 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
 obj-y += accel/
 obj-y += adc/
 obj-y += amplifiers/
+obj-y += chemical/
 obj-y += common/
 obj-y += dac/
 obj-y += gyro/
diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
new file mode 100644
index 000..04906af
--- /dev/null
+++ b/drivers/iio/chemical/Kconfig
@@ -0,0 +1,15 @@
+#
+# Chemical sensors
+#
+
+menu "Indoor Air Quality sensors"
+
+config VZ89X
+   tristate "SGX Sensortech MiCS VZ89X VOC sensor"
+   depends on I2C
+   help
+ Say Y here to build I2C interface support for the SGX
+ Sensortech MiCS VZ89X VOC (Volatile Organic Compounds)
+ sensors
+
+endmenu
diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
new file mode 100644
index 000..7292f2d
--- /dev/null
+++ b/drivers/iio/chemical/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO chemical sensors
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_VZ89X)+= vz89x.o
diff --git a/drivers/iio/chemical/vz89x.c b/drivers/iio/chemical/vz89x.c
new file mode 100644
index 000..b454200
--- /dev/null
+++ b/drivers/iio/chemical/vz89x.c
@@ -0,0 +1,237 @@
+/*
+ * vz89x.c - Support for SGX Sensortech MiCS VZ89X VOC sensors
+ *
+ * Copyright (C) 2015 Matt Ranostay 
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define VZ89X_REG_MEASUREMENT  0x09
+#define VZ89X_REG_MEASUREMENT_SIZE 6
+
+#define VZ89X_VOC_CO2_IDX  0
+#define VZ89X_VOC_SHORT_IDX1
+#define 

[PATCH v5 3/4] devicetree: add SGX Sensortech vendor id

[Matt Ranostay]

Signed-off-by: Matt Ranostay 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac5f0c3..281e8f0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -191,6 +191,7 @@ sbs Smart Battery System
 schindler  Schindler
 seagateSeagate Technology PLC
 semtechSemtech Corporation
+sgxSGX Sensortech
 sharp  Sharp Corporation
 silSilicon Image
 silabs Silicon Laboratories
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 1/4] iio: chemical: Add IIO_CONCENTRATION channel type

[Matt Ranostay]

There are air quality sensors that report data back in parts per million
of VOC (Volatile Organic Compounds) which are usually indexed from CO2
or another common pollutant.

This patchset adds an IIO_CONCENTRATION type that returns a percentage
of substance because no other channels types fit this use case.
Modifiers for IIO_MOD_CO2 and IIO_MOD_VOC gas types are defined.

Signed-off-by: Matt Ranostay 
---
 Documentation/ABI/testing/sysfs-bus-iio | 11 +++
 drivers/iio/industrialio-core.c |  3 +++
 include/uapi/linux/iio/types.h  |  3 +++
 3 files changed, 17 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 42d360f..682c070 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1459,3 +1459,14 @@ Description:
measurements and return the average value as output data. Each
value resulted from [_name]_oversampling_ratio 
measurements
is considered as one sample for 
[_name]_sampling_frequency.
+
+What:  /sys/bus/iio/devices/iio:deviceX/in_concentration_raw
+What:  /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
+What:  /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw
+What:  /sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw
+What:  /sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw
+What:  /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
+KernelVersion: 4.3
+Contact:   linux-...@vger.kernel.org
+Description:
+   Raw (unscaled no offset etc.) percentage reading of a substance.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index b3fcc2c..8eb6064 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -75,6 +75,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_ENERGY] = "energy",
[IIO_DISTANCE] = "distance",
[IIO_VELOCITY] = "velocity",
+   [IIO_CONCENTRATION] = "concentration",
 };
 
 static const char * const iio_modifier_names[] = {
@@ -111,6 +112,8 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_ROOT_SUM_SQUARED_X_Y_Z] = "sqrt(x^2+y^2+z^2)",
[IIO_MOD_I] = "i",
[IIO_MOD_Q] = "q",
+   [IIO_MOD_CO2] = "co2",
+   [IIO_MOD_VOC] = "voc",
 };
 
 /* relies on pairs of these shared then separate */
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 2f8b117..1e4c4e3 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -35,6 +35,7 @@ enum iio_chan_type {
IIO_ENERGY,
IIO_DISTANCE,
IIO_VELOCITY,
+   IIO_CONCENTRATION,
 };
 
 enum iio_modifier {
@@ -72,6 +73,8 @@ enum iio_modifier {
IIO_MOD_ROOT_SUM_SQUARED_X_Y_Z,
IIO_MOD_I,
IIO_MOD_Q,
+   IIO_MOD_CO2,
+   IIO_MOD_VOC,
 };
 
 enum iio_event_type {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 2/4] iio: resistance: add IIO_RESISTANCE channel type

[Matt Ranostay]

Signed-off-by: Matt Ranostay 
---
 Documentation/ABI/testing/sysfs-bus-iio | 8 
 drivers/iio/industrialio-core.c | 1 +
 include/uapi/linux/iio/types.h  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 682c070..a91af51 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1470,3 +1470,11 @@ KernelVersion:   4.3
 Contact:   linux-...@vger.kernel.org
 Description:
Raw (unscaled no offset etc.) percentage reading of a substance.
+
+What:  /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
+What:  /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
+KernelVersion: 4.3
+Contact:   linux-...@vger.kernel.org
+Description:
+   Raw (unscaled no offset etc.) resistance reading that can be 
processed
+   into an ohm value.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 8eb6064..80439a6 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -76,6 +76,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_DISTANCE] = "distance",
[IIO_VELOCITY] = "velocity",
[IIO_CONCENTRATION] = "concentration",
+   [IIO_RESISTANCE] = "resistance",
 };
 
 static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 1e4c4e3..7c63bd6 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -36,6 +36,7 @@ enum iio_chan_type {
IIO_DISTANCE,
IIO_VELOCITY,
IIO_CONCENTRATION,
+   IIO_RESISTANCE,
 };
 
 enum iio_modifier {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The default value of enable_gpio in pwm-backlight driver?

[Yingjoe Chen]

Hi Alexandre, Thierry,


On Thu, 2015-09-03 at 21:08 +0800, YH Huang wrote:
<...>
> From  Alexandre Courbot <>
> Subject   [PATCH 2/2] pwm-backlight: switch to gpiod interface
> Date  Thu, 27 Feb 2014 14:53:34 +0900
> 
> Switch to the new gpiod interface, which allows to handle GPIO
> properties such as active low transparently and removes a whole bunch of
> code.
> 
> There are still a couple of users of this driver that rely on passing
> the enable GPIO number through platform data, so a fallback mechanism
> using a GPIO number is still available to avoid breaking them. It will
> be removed once current users have switched to the GPIO lookup tables
> provided by the gpiod interface.
> 
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> 
> @@ -265,26 +245,39 @@ static int pwm_backlight_probe(struct
> platform_device *pdev)
>   pb->dev = >dev;
>   pb->enabled = false;
>  
> - if (gpio_is_valid(pb->enable_gpio)) {
> - unsigned long flags;
> -
> - if (pb->enable_gpio_flags & PWM_BACKLIGHT_GPIO_ACTIVE_LOW)
> - flags = GPIOF_OUT_INIT_HIGH;
> - else
> - flags = GPIOF_OUT_INIT_LOW;

In commit 257462dbf3ed ("pwm-backlight: switch to gpiod interface").
It seems to me the original code is trying to make it default disable...

> + pb->enable_gpio = devm_gpiod_get(>dev, "enable");
> + if (IS_ERR(pb->enable_gpio)) {
> + ret = PTR_ERR(pb->enable_gpio);
> + if (ret == -ENOENT) {
> + pb->enable_gpio = NULL;
> + ret = 0;
> + } else {
> + goto err_alloc;
> + }
> + }
>  
> - ret = gpio_request_one(pb->enable_gpio, flags, "enable");
> + /*
> +  * Compatibility fallback for drivers still using the integer GPIO
> +  * platform data. Must go away soon.
> +  */
> + if (pb->enable_gpio == NULL && gpio_is_valid(data->enable_gpio)) {
> + ret = devm_gpio_request_one(>dev, data->enable_gpio,
> + GPIOF_OUT_INIT_HIGH, "enable");
>   if (ret < 0) {
>   dev_err(>dev, "failed to request GPIO#%d: %d\n",
> - pb->enable_gpio, ret);
> + data->enable_gpio, ret);
>   goto err_alloc;
>   }
> + pb->enable_gpio = gpio_to_desc(data->enable_gpio);
>   }
>  
> + if (pb->enable_gpio)
> + gpiod_direction_output(pb->enable_gpio, 1);

But the new code here set it to enable. Is this on purpose, or am I miss
read anything?

Joe.C


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Documentation: bindings: add description of phy for sdhci-of-arasan

[Sören Brinkmann]

Hi Shawn,

On Fri, 2015-09-11 at 04:55PM +0800, Shawn Lin wrote:
> This patch adds phys and phy-names for sdhci-of-arasan as optional
> properties, and details the example as well.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
>  Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index da541c3..0264d5f 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -1,11 +1,12 @@
>  Device Tree Bindings for the Arasan SDHCI Controller
>  
> -  The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
> -  deviations are documented here.
> +  The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
> +  Only deviations are documented here.
>  
>[1] Documentation/devicetree/bindings/mmc/mmc.txt
>[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
>[3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +  [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
>  
>  Required Properties:
>- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
> @@ -16,6 +17,9 @@ Required Properties:
>- interrupts: Interrupt specifier
>- interrupt-parent: Phandle for the interrupt controller that services
> interrupts for this device.
> +Optional Properties:
> +  - phys: From PHY bindings: Phandle for the Generic PHY for arasan.
> +  - phy-names:  MUST be "phy_arasan".

This might be a dumb question, but, is the external phy actually
optional? Or is it mandatory for certain implementations of the IP.
In the latter case, it should probably be a mandatory property depending
on the compatible string matching an implementation that requires an
external phy (accordingly, the implementation might have to treat it
that way too).

Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings

[Yuantian Tang]

Hello Tejun,

The toolchain I used is:
gcc version 4.8.3 20140401 (prerelease) (Linaro GCC 4.8-2014.04)

I have not found this warning using this tool chain with -Wuninitialized flag.

Regards,
Yuantian 

> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
> Sent: Friday, September 11, 2015 9:55 PM
> To: Tang Yuantian-B29983 
> Cc: hdego...@redhat.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; Fengguang Wu
> 
> Subject: Re: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings
> 
> Hello, Yuantian.
> 
> On Fri, Sep 11, 2015 at 05:27:25AM +, Yuantian Tang wrote:
> > Hi Tejun,
> >
> > Could you please take the version 1 patch?
> > The version 2 patch can't address these warnings, and the version 1 can
> definitely remove them.
> > In this case, that would cause any hidden bugs, so no worries.
> 
> Ugh... I really hate changes which are made to just work around compiler
> silliness.  If this is something which goes away with newer gcc, Fengguang can
> just make it as a known false positive.  Yuantian, which compiler are you
> using?
> 
> Thanks.
> 
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Bugfix 1/3] eata: Use IDA to manage eata board IDs

[Jiang Liu]

Use IDA to manage eata board IDs, so we could dynamically allocate
and free board IDs later.

Signed-off-by: Jiang Liu 
---
 drivers/scsi/eata.c |   46 ++
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..b45d3b532b70 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -491,6 +491,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -837,9 +838,8 @@ struct hostdata {
 static struct Scsi_Host *sh[MAX_BOARDS];
 static const char *driver_name = "EATA";
 static char sha[MAX_BOARDS];
-
-/* Initialize num_boards so that ihdlr can work while detect is in progress */
-static unsigned int num_boards = MAX_BOARDS;
+static DEFINE_IDA(eata_ida);
+static DECLARE_BITMAP(eata_board_bitmap, MAX_BOARDS);
 
 static unsigned long io_port[] = {
 
@@ -1509,6 +1509,23 @@ static int option_setup(char *str)
return 1;
 }
 
+static unsigned int port_probe(unsigned long port_base,
+  struct scsi_host_template *tpnt)
+{
+   int id;
+
+   id = ida_simple_get(_ida, 0, MAX_BOARDS, GFP_KERNEL);
+   if (id >= 0) {
+   set_bit(id, eata_board_bitmap);
+   if (port_detect(port_base, id, tpnt))
+   return id;
+   clear_bit(id, eata_board_bitmap);
+   ida_simple_remove(_ida, id);
+   }
+
+   return -1;
+}
+
 static void add_pci_ports(void)
 {
 #if defined(CONFIG_PCI)
@@ -1548,7 +1565,7 @@ static void add_pci_ports(void)
 
 static int eata2x_detect(struct scsi_host_template *tpnt)
 {
-   unsigned int j = 0, k;
+   unsigned int k, count = 0;
 
tpnt->proc_name = "eata2x";
 
@@ -1582,17 +1599,12 @@ static int eata2x_detect(struct scsi_host_template 
*tpnt)
enable_pci_ports();
}
 
-   for (k = 0; io_port[k]; k++) {
+   for (k = 0; io_port[k]; k++)
+   if (io_port[k] != SKIP &&
+   port_probe(io_port[k], tpnt) >= 0)
+   count++;
 
-   if (io_port[k] == SKIP)
-   continue;
-
-   if (j < MAX_BOARDS && port_detect(io_port[k], j, tpnt))
-   j++;
-   }
-
-   num_boards = j;
-   return j;
+   return count;
 }
 
 static void map_dma(unsigned int i, struct hostdata *ha)
@@ -2530,14 +2542,16 @@ static irqreturn_t ihdlr(struct Scsi_Host *shost)
 static irqreturn_t do_interrupt_handler(int dummy, void *shap)
 {
struct Scsi_Host *shost;
-   unsigned int j;
+   unsigned int j = (unsigned int)((char *)shap - sha);
unsigned long spin_flags;
irqreturn_t ret;
 
/* Check if the interrupt must be processed by this handler */
-   if ((j = (unsigned int)((char *)shap - sha)) >= num_boards)
+   if (j >= MAX_BOARDS || !test_bit(j, eata_board_bitmap))
return IRQ_NONE;
shost = sh[j];
+   if (!shost)
+   return IRQ_NONE;
 
spin_lock_irqsave(shost->host_lock, spin_flags);
ret = ihdlr(shost);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] thermal: imx: register irq handler later in probe

[Bai Ping]

The irq handler should be registered after the tempmon
module has been initialized in a known state and the
thermal_zone and cpu_cooling device have been registered
successfully. Otherwise, if the irq is triggled earlier
before thermal probe has been finished, it may lead to
'NULL' pointer kernel panic.

Signed-off-by: Bai Ping 
---
 drivers/thermal/imx_thermal.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 4bec1d3..acd1c78 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -487,14 +487,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
 
-   ret = devm_request_threaded_irq(>dev, data->irq,
-   imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread,
-   0, "imx_thermal", data);
-   if (ret < 0) {
-   dev_err(>dev, "failed to request alarm irq: %d\n", ret);
-   return ret;
-   }
-
platform_set_drvdata(pdev, data);
 
ret = imx_get_sensor_data(pdev);
@@ -571,6 +563,17 @@ static int imx_thermal_probe(struct platform_device *pdev)
regmap_write(map, TEMPSENSE0 + REG_CLR, TEMPSENSE0_POWER_DOWN);
regmap_write(map, TEMPSENSE0 + REG_SET, TEMPSENSE0_MEASURE_TEMP);
 
+   ret = devm_request_threaded_irq(>dev, data->irq,
+   imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread,
+   0, "imx_thermal", data);
+   if (ret < 0) {
+   dev_err(>dev, "failed to request alarm irq: %d\n", ret);
+   clk_disable_unprepare(data->thermal_clk);
+   thermal_zone_device_unregister(data->tz);
+   cpufreq_cooling_unregister(data->cdev);
+   return ret;
+   }
+
data->irq_enabled = true;
data->mode = THERMAL_DEVICE_ENABLED;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Bugfix 3/3] eata: Enhance eata driver to support PCI device hot-removal

[Jiang Liu]

Due to having no hardware for testing, this is just a sample code
to support PCI device hot-removal. It just passing compilation,
no any tests.

Signed-off-by: Jiang Liu 
---
 drivers/scsi/eata.c |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index b92e6856f909..f3bd7cbf260e 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1474,6 +1474,21 @@ static unsigned int port_probe(unsigned long port_base,
 #ifdef CONFIG_PCI
 static int eata2x_pci_device_count;
 
+/* TODO: need help here to shutdown the scsi host and release resources */
+static void port_remove(unsigned int id, resource_size_t port_base,
+   struct pci_dev *pdev)
+{
+   struct Scsi_Host *shost = sh[id];
+
+   /* TODO: stop scsi device */
+   scsi_unregister(shost);
+   /* TODO: clean up resources allocated by port_detect() */
+   clear_bit(id, eata_board_bitmap);
+   free_irq(shost->irq, [id]);
+   release_region(port_base, REGION_SIZE);
+   ida_simple_remove(_ida, id);
+}
+
 static int eata2x_pci_probe(struct pci_dev *dev, const struct pci_device_id 
*id)
 {
int i, ret = -ENXIO;
@@ -1521,6 +1536,16 @@ out_error:
return ret;
 }
 
+static void eata2x_pci_remove(struct pci_dev *pdev)
+{
+   int id = (int)(long)dev_get_drvdata(>dev);
+   resource_size_t port_base;
+
+   port_base = pci_resource_start(pdev, 0) + PCI_BASE_ADDRESS_0;
+   port_remove(id, port_base, pdev);
+   pci_disable_device(pdev);
+}
+
 static struct pci_device_id eata2x_tbl[] = {
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SCSI << 8, PCI_ANY_ID) },
{ },
@@ -1531,6 +1556,7 @@ static struct pci_driver eata2x_pci_driver = {
.name   = "eata",
.id_table   = eata2x_tbl,
.probe  = eata2x_pci_probe,
+   .remove = eata2x_pci_remove,
 };
 
 static int eata2x_probe_pci_devices(struct scsi_host_template *tpnt)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Bugfix 0/3] Convert eata driver to a normal PCI device driver

[Jiang Liu]

Hi Authur,
As suggested by Bjorn, patch 1-2 set implement a PCI device
driver to manage eata PCI devices. And patch 3 tries to support PCI
device hot-removal for eata, but I have no change to test due to 
limited knowledge about scsi subsystem and lacking of hardware for
tests.
So you could please help to test patch 1-2? Patch 3 is just
for comments.
Thanks!
Gerry

Jiang Liu (3):
  eata: Use IDA to manage eata board IDs
  eata: Implement PCI driver to manage eata PCI devices
  eata: Enhance eata driver to support PCI device hot-removal

 drivers/scsi/eata.c |  232 +++
 1 file changed, 125 insertions(+), 107 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Bugfix 2/3] eata: Implement PCI driver to manage eata PCI devices

[Jiang Liu]

Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related

Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
will be called by pci_device_probe() to allocate PCI legacy IRQs
when binding PCI drivers to PCI devices.

But the eata driver directly accesses PCI devices without implementing
corresponding PCI drivers, so pcibios_alloc_irq() won't be called for
those PCI devices and wrong IRQ number may be used to manage the PCI
device.

This patch implements a PCI device driver to manage eata PCI devices,
so eata driver could properly cooperate with the PCI core. It also
provides headroom for PCI hotplug with eata driver.

Signed-off-by: Jiang Liu 
---
 drivers/scsi/eata.c |  170 ++-
 1 file changed, 74 insertions(+), 96 deletions(-)

diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index b45d3b532b70..b92e6856f909 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -850,10 +850,6 @@ static unsigned long io_port[] = {
/* First ISA */
0x1f0,
 
-   /* Space for MAX_PCI ports possibly reported by PCI_BIOS */
-   SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
-   SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
-
/* MAX_EISA ports */
0x1c88, 0x2c88, 0x3c88, 0x4c88, 0x5c88, 0x6c88, 0x7c88, 0x8c88,
0x9c88, 0xac88, 0xbc88, 0xcc88, 0xdc88, 0xec88, 0xfc88,
@@ -1024,60 +1020,13 @@ static int read_pio(unsigned long iobase, ushort * 
start, ushort * end)
return 0;
 }
 
-static struct pci_dev *get_pci_dev(unsigned long port_base)
-{
-#if defined(CONFIG_PCI)
-   unsigned int addr;
-   struct pci_dev *dev = NULL;
-
-   while ((dev = pci_get_class(PCI_CLASS_STORAGE_SCSI << 8, dev))) {
-   addr = pci_resource_start(dev, 0);
-
-#if defined(DEBUG_PCI_DETECT)
-   printk("%s: get_pci_dev, bus %d, devfn 0x%x, addr 0x%x.\n",
-  driver_name, dev->bus->number, dev->devfn, addr);
-#endif
-
-   /* we are in so much trouble for a pci hotplug system with this 
driver
-* anyway, so doing this at least lets people unload the driver 
and not
-* cause memory problems, but in general this is a bad thing to 
do (this
-* driver needs to be converted to the proper PCI api 
someday... */
-   pci_dev_put(dev);
-   if (addr + PCI_BASE_ADDRESS_0 == port_base)
-   return dev;
-   }
-#endif /* end CONFIG_PCI */
-   return NULL;
-}
-
-static void enable_pci_ports(void)
-{
-#if defined(CONFIG_PCI)
-   struct pci_dev *dev = NULL;
-
-   while ((dev = pci_get_class(PCI_CLASS_STORAGE_SCSI << 8, dev))) {
-#if defined(DEBUG_PCI_DETECT)
-   printk("%s: enable_pci_ports, bus %d, devfn 0x%x.\n",
-  driver_name, dev->bus->number, dev->devfn);
-#endif
-
-   if (pci_enable_device(dev))
-   printk
-   ("%s: warning, pci_enable_device failed, bus %d 
devfn 0x%x.\n",
-driver_name, dev->bus->number, dev->devfn);
-   }
-
-#endif /* end CONFIG_PCI */
-}
-
 static int port_detect(unsigned long port_base, unsigned int j,
-   struct scsi_host_template *tpnt)
+  struct scsi_host_template *tpnt, struct pci_dev *pdev)
 {
unsigned char irq, dma_channel, subversion, i, is_pci = 0;
unsigned char protocol_rev;
struct eata_info info;
char *bus_type, dma_name[16];
-   struct pci_dev *pdev;
/* Allowed DMA channels for ISA (0 indicates reserved) */
unsigned char dma_channel_table[4] = { 5, 6, 7, 0 };
struct Scsi_Host *shost;
@@ -1199,15 +1148,8 @@ static int port_detect(unsigned long port_base, unsigned 
int j,
("%s: warning, LEVEL triggering is suggested for IRQ %u.\n",
 name, irq);
 
-   if (is_pci) {
-   pdev = get_pci_dev(port_base);
-   if (!pdev)
-   printk
-   ("%s: warning, failed to get pci_dev structure.\n",
-name);
-   } else
-   pdev = NULL;
-
+   if (is_pci && !pdev)
+   printk("%s: warning, failed to get pci_dev structure.\n", name);
if (pdev && (irq != pdev->irq)) {
printk("%s: IRQ %u mapped to IO-APIC IRQ %u.\n", name, irq,
   pdev->irq);
@@ -1510,14 +1452,17 @@ static int option_setup(char *str)
 }
 
 static unsigned int port_probe(unsigned long port_base,
-  struct 

Re: [PATCH v4 0/5] Let the power allocator thermal governor run on any thermal zone

[Eduardo Valentin]

Javi,

On Wed, Aug 26, 2015 at 02:26:39PM +0100, Javi Merino wrote:
> Relax the thermal governor requirements of sustainable_power and at
> least two trip points so that it can be bound to any thermal zone.
> Its behavior won't be optimal, it would be the best it can with the
> data provided.
> 
> Changes since v3:
>- Don't hardcode a value for sustainable power and re-estimate
>  the PID controllers every time if no sustainable power is given
>  as suggested by Eduardo Valentin.
>- power_actor_get_min_power() moved to a patch of its own.
> 
> Changes since v2:
>   - Typos suggested by Daniel Kurtz
> 
> Changes since v1:
>   - Let the power allocator governor operate if the thermal zone
> doesn't have tzp as suggested by Chung-yih Wang
> 
> Javi Merino (5):
>   thermal: Add a function to get the minimum power
>   thermal: power_allocator: relax the requirement of a sustainable_power
> in tzp
>   thermal: power_allocator: relax the requirement of two passive trip   
>  points
>   thermal: power_allocator: don't require tzp to be present for the
> thermal zone
>   thermal: power_allocator: exit early if there are no cooling devices

This patch set does not apply clean. Could you please refresh it?

> 
>  Documentation/thermal/power_allocator.txt |   2 +-
>  drivers/thermal/power_allocator.c | 241 
> ++
>  drivers/thermal/thermal_core.c|  28 
>  include/linux/thermal.h   |   6 +
>  4 files changed, 212 insertions(+), 65 deletions(-)
> 
> -- 
> 1.9.1
> 


signature.asc
Description: Digital signature

Re: [PATCH 2/2] Documentation: bindings: add description of phy for sdhci-of-arasan

[Shawn Lin]

在 2015/9/14 10:47, Sören Brinkmann 写道:

Hi Shawn,

On Fri, 2015-09-11 at 04:55PM +0800, Shawn Lin wrote:

This patch adds phys and phy-names for sdhci-of-arasan as optional
properties, and details the example as well.

Signed-off-by: Shawn Lin 
---

  Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index da541c3..0264d5f 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -1,11 +1,12 @@
  Device Tree Bindings for the Arasan SDHCI Controller

-  The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
-  deviations are documented here.
+  The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
+  Only deviations are documented here.

[1] Documentation/devicetree/bindings/mmc/mmc.txt
[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
[3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+  [4] Documentation/devicetree/bindings/phy/phy-bindings.txt

  Required Properties:
- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
@@ -16,6 +17,9 @@ Required Properties:
- interrupts: Interrupt specifier
- interrupt-parent: Phandle for the interrupt controller that services
  interrupts for this device.
+Optional Properties:
+  - phys: From PHY bindings: Phandle for the Generic PHY for arasan.
+  - phy-names:  MUST be "phy_arasan".


This might be a dumb question, but, is the external phy actually
optional? Or is it mandatory for certain implementations of the IP.
In the latter case, it should probably be a mandatory property depending
on the compatible string matching an implementation that requires an
external phy (accordingly, the implementation might have to treat it


From my soc team's reponse, there is no way to bypass controller to IO 
if no phy supported. So it should be the latter case you mentioned for 
arasan.sdhci-5.1.


Thanks for point out it, really helpful.

I will fix it in v2.


that way too).

Sören






--
Best Regards
Shawn Lin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: add CS2000 Fractional-N driver

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch adds CS2000 Fractional-N driver as clock provider.
It is useful if it supports runtime clock setting, but it supports
fixed clock rate only at this point.

Signed-off-by: Kuninori Morimoto 
---
 .../devicetree/bindings/clock/cs2000-cp.txt|  20 ++
 drivers/clk/Kconfig|   6 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-cs2000-cp.c| 379 +
 4 files changed, 406 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/cs2000-cp.txt
 create mode 100644 drivers/clk/clk-cs2000-cp.c

diff --git a/Documentation/devicetree/bindings/clock/cs2000-cp.txt 
b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
new file mode 100644
index 000..e79cf10
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
@@ -0,0 +1,20 @@
+CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
+
+Required properties:
+
+- compatible:  "cirrus,cs2000-cp"
+- reg: The chip select number on the I2C bus
+- clocks:  common clock binding for CLK_IN, XTI/REF_CLK
+- clock-frequency: clock frequency of CLK_OUT
+
+Example:
+
+ {
+   ...
+   cs2000: clk_multiplier@0x4f {
+   compatible = "cirrus,cs2000-cp";
+   reg = <0x4f>;
+   clocks = <_sound 0>, <_clk>;
+   clock-frequency = <24576000>; /* 1/1 divide */
+   };
+};
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 42f7120..5933e5f 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -95,6 +95,12 @@ config COMMON_CLK_CDCE925
  Given a target output frequency, the driver will set the PLL and
  divider to best approximate the desired output.
 
+config COMMON_CLK_CS2000_CP
+   tristate "Clock driver for CS2000 Fractional-N Clock Synthesizer & 
Clock Multiplier"
+   depends on I2C
+   help
+ If you say yes here you get support for the CS2000 clock multiplier
+
 config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 9d31e2c..2fb77a8 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)   += clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)   += clk-axm5516.o
 obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
 obj-$(CONFIG_COMMON_CLK_CDCE706)   += clk-cdce706.o
+obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
 obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
 obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
new file mode 100644
index 000..13a1dfa
--- /dev/null
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -0,0 +1,379 @@
+/*
+ * CS2000  --  CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ * Kuninori Morimoto 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CLK_MAIN   0 /* CLK_IN  on datasheet */
+#define CLK_IN 1 /* REF_CLK on datasheet */
+
+#define CH_MAX 4
+
+#define DEVICE_ID  0x1
+#define DEVICE_CTRL0x2
+#define DEVICE_CFG10x3
+#define DEVICE_CFG20x4
+#define GLOBAL_CFG 0x5
+#define Ratio_Add(x, nth)  (6 + (x * 4) + (nth))
+#define Ratio_Val(x, nth)  ((x >> (24 - (8 * nth))) & 0xFF)
+#define FUNC_CFG1  0x16
+#define FUNC_CFG2  0x17
+
+/* DEVICE_CTRL */
+#define PLL_UNLOCK (1 << 7)
+
+/* DEVICE_CFG1 */
+#define RSEL(x)(((x) & 0x3) << 3)
+#define RSEL_MASK  RSEL(0x3)
+#define ENDEV1 (0x1)
+
+/* GLOBAL_CFG */
+#define ENDEV2 (0x1)
+
+
+#define CH_ERR(ch) ((ch < 0) || (ch >= CH_MAX))
+
+struct cs2000_priv {
+   struct clk *clk_main;
+   struct clk *clk_in;
+   struct clk *clk_out;
+};
+
+static const struct of_device_id cs2000_of_match[] = {
+   { .compatible = "cirrus,cs2000-cp", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, cs2000_of_match);
+
+static const struct i2c_device_id cs2000_id[] = {
+   { "cs2000-cp", },
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, cs2000_id);
+
+#define cs2000_read(c, addr)   i2c_smbus_read_byte_data(c, addr)
+static void cs2000_write(struct i2c_client *client, u8 addr, u8 val)
+{
+   struct device *dev = >dev;
+
+   dev_dbg(dev, "0x%02x : 0x%02x\n", addr, val);
+
+   i2c_smbus_write_byte_data(client, addr, val);
+}
+
+static void cs2000_bset(struct i2c_client *client, u8 addr, u8 mask, u8 val)
+{
+   u32 data;
+
+   data = cs2000_read(client, 

Re: List corruption on epoll_ctl(EPOLL_CTL_DEL) an AF_UNIX socket

[Eric Wong]

+cc Jason Baron since he might be able to provide more insight into
epoll.

Mathias Krause  wrote:
> Hi,
> 
> this is an attempt to resurrect the thread initially started here:
> 
>   http://thread.gmane.org/gmane.linux.network/353003
> 
> As that patch fixed the issue for the mentioned reproducer, it did not
> fix the bug for the production code Olivier is using. :(
> 
> Changing the reproducer only slightly allows me to trigger the following
> list debug splat (CONFIG_DEBUG_LIST=y) reliable within seconds -- even
> with the above linked patch applied:
> 
> [   50.264249] [ cut here ]
> [   50.264249] WARNING: CPU: 0 PID: 214 at lib/list_debug.c:59 
> __list_del_entry+0xa4/0xd0()
> [   50.264249] list_del corruption. prev->next should be 88003c2c1bb8, 
> but was 88003f07bbb8
> [   50.264249] Modules linked in: ipv6 pcspkr serio_raw microcode virtio_net 
> virtio_pci virtio_ring virtio sr_mod cdrom
> [   50.264249] CPU: 0 PID: 214 Comm: epoll_bug Not tainted 4.2.0 #75
> [   50.264249] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.7.5-20140531_083030-gandalf 04/01/2014
> [   50.264249]  817e902e 88087d08 8155593c 
> 0007
> [   50.264249]  88087d58 88087d48 8105202a 
> 0001
> [   50.264249]  88003c2c1bb8 88003f07bb80 0286 
> 88003f736640
> [   50.264249] Call Trace:
> [   50.264249]  [] dump_stack+0x4c/0x65
> [   50.264249]  [] warn_slowpath_common+0x8a/0xc0
> [   50.264249]  [] warn_slowpath_fmt+0x46/0x50
> [   50.264249]  [] __list_del_entry+0xa4/0xd0
> [   50.264249]  [] list_del+0x11/0x40
> [   50.264249]  [] remove_wait_queue+0x29/0x40
> [   50.264249]  [] ep_unregister_pollwait.isra.6+0x58/0x1a0
> [   50.264249]  [] ? 
> ep_unregister_pollwait.isra.6+0xa9/0x1a0
> [   50.264249]  [] ep_remove+0x22/0x110
> [   50.264249]  [] SyS_epoll_ctl+0x62b/0xf70
> [   50.264249]  [] ? lockdep_sys_exit_thunk+0x12/0x14
> [   50.264249]  [] entry_SYSCALL_64_fastpath+0x12/0x6f
> [   50.264249] ---[ end trace d9af9b915df9667e ]---
> [   50.572100] [ cut here ]
> [   50.572100] WARNING: CPU: 1 PID: 212 at lib/list_debug.c:62 
> __list_del_entry+0xc3/0xd0()
> [   50.584263] list_del corruption. next->prev should be 88003f664c90, 
> but was 88003f0cb5b8
> [   50.584263] Modules linked in: ipv6 pcspkr serio_raw microcode virtio_net 
> virtio_pci virtio_ring virtio sr_mod cdrom
> [   50.584263] CPU: 1 PID: 212 Comm: epoll_bug Tainted: GW   
> 4.2.0 #75
> [   50.584263] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.7.5-20140531_083030-gandalf 04/01/2014
> [   50.584263]  817e902e 88003d37fce8 8155593c 
> 0007
> [   50.584263]  88003d37fd38 88003d37fd28 8105202a 
> 0001
> [   50.584263]  88003f664c90 88003f0cb580 0282 
> 88003f731740
> [   50.584263] Call Trace:
> [   50.584263]  [] dump_stack+0x4c/0x65
> [   50.584263]  [] warn_slowpath_common+0x8a/0xc0
> [   50.584263]  [] warn_slowpath_fmt+0x46/0x50
> [   50.584263]  [] __list_del_entry+0xc3/0xd0
> [   50.584263]  [] list_del+0x11/0x40
> [   50.584263]  [] remove_wait_queue+0x29/0x40
> [   50.584263]  [] ep_unregister_pollwait.isra.6+0x58/0x1a0
> [   50.584263]  [] ? 
> ep_unregister_pollwait.isra.6+0xa9/0x1a0
> [   50.584263]  [] ep_remove+0x22/0x110
> [   50.584263]  [] eventpoll_release_file+0x62/0xa0
> [   50.584263]  [] __fput+0x1af/0x200
> [   50.584263]  [] ? int_very_careful+0x5/0x3f
> [   50.584263]  [] fput+0xe/0x10
> [   50.584263]  [] task_work_run+0x8d/0xc0
> [   50.584263]  [] do_notify_resume+0x4f/0x60
> [   50.584263]  [] int_signal+0x12/0x17
> [   50.584263] ---[ end trace d9af9b915df9667f ]---
> [   50.584263] BUG: spinlock already unlocked on CPU#1, epoll_bug/212
> [   50.584263]  lock: 0x88003f0cb580, .magic: dead4ead, .owner: 
> /-1, .owner_cpu: -1
> [   50.584263] CPU: 1 PID: 212 Comm: epoll_bug Tainted: GW   
> 4.2.0 #75
> [   50.584263] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.7.5-20140531_083030-gandalf 04/01/2014
> [   50.584263]  88003f0cb580 88003d37fd38 8155593c 
> 0007
> [   50.584263]   88003d37fd58 810a3375 
> 88003f0cb580
> [   50.584263]  817b9cc8 88003d37fd78 810a33f6 
> 88003f0cb580
> [   50.584263] Call Trace:
> [   50.584263]  [] dump_stack+0x4c/0x65
> [   50.584263]  [] spin_dump+0x85/0xe0
> [   50.584263]  [] spin_bug+0x26/0x30
> [   50.584263]  [] do_raw_spin_unlock+0x75/0xa0
> [   50.584263]  [] _raw_spin_unlock_irqrestore+0x2c/0x50
> [   50.584263]  [] remove_wait_queue+0x34/0x40
> [   50.584263]  [] ep_unregister_pollwait.isra.6+0x58/0x1a0
> [   50.584263]  [] ? 
> ep_unregister_pollwait.isra.6+0xa9/0x1a0
> [   50.584263]  [] ep_remove+0x22/0x110
> [   50.584263]  [] eventpoll_release_file+0x62/0xa0
> [   50.584263]  

linux-next: Tree for Sep 14

[Stephen Rothwell]

Hi all,

Changes since 20150912:

Dropped tree: akpm-current (build conflict)

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto something very old :-(

The bluetooth tree gained an expected build failure from an interaction
with a patch from Andrew's series.  I applied the fixups that Andrew
has been using.

The kdbus tree gained a conflict against Linus' tree.

The akpm-current tree still had its build failure so I dropped it
for today.

The akpm tree lost 2 patches to the bluetooth tree merge.

Non-merge commits (relative to Linus' tree): 950
 743 files changed, 62186 insertions(+), 9127 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 226 trees (counting Linus' and 33 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (6ff33f3902c3 Linux 4.3-rc1)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (c2172ce23030 Merge branch 'uaccess' into fixes)
Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather 
than duplicating its implementation)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (e297c939b745 powerpc/MSI: Fix race condition in 
tearing down MSI interrupts)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (e8684c88774c irda: ali-ircc: Fix deadlock in 
ali_ircc_sir_change_speed())
Merging ipsec/master (93efac3f2e03 ipv6: Fix IPsec pre-encap fragmentation 
check)
Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal 
PCM order)
Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses 
on PA-RISC)
Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module 
parameter for MSI interrupts)
Merging driver-core.current/driver-core-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging tty.current/tty-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging usb.current/usb-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() 
call to error pathway)
Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 
LTE/EV-DO/HSPA+ Gobi 4G Module)
Merging staging.current/staging-linus (8b5081c876bd staging: unisys: visornic: 
handle error return from device registration)
Merging char-misc.current/char-misc-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging input-current/for-linus (53431d0a3534 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (84cba178a3b8 crypto: testmgr - don't copy from 
source IV too much)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix 
futex_cmp_requeue_pi() error handling)
Merging backlight-fixes/for-backlight-fixes 

[PATCHv2 00/10] thermal: add COMPILE_TEST (on drivers)

[Eduardo Valentin]

Hi,

This is v2. Now I tested the series with bfin as target, to avoid
false positives. The difference from V1:
- Added acked-bys
- Removed patches that could cause compilation issues


BR,

Eduardo Valentin (10):
  thermal: hisi: allow compile test
  thermal: spear: allow compile test
  thermal: rockchip: allow compile test
  thermal: kirkwood: allow compile test
  thermal: dove: allow compile test
  thermal: armada: allow compile test
  thermal: exynos: allow compile test
  thermal: qcom_spmi: allow compile test
  thermal: ti-soc: allow compile test
  thermal: ti-soc: Kconfig fix to avoid menu showing wrongly

 drivers/thermal/Kconfig| 17 +
 drivers/thermal/ti-soc-thermal/Kconfig |  8 +++-
 2 files changed, 12 insertions(+), 13 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 01/10] thermal: hisi: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to hisi driver to facilitate maintenance.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 118938e..f2b1d31 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -163,7 +163,7 @@ config THERMAL_EMULATION
 
 config HISI_THERMAL
tristate "Hisilicon thermal driver"
-   depends on ARCH_HISI && CPU_THERMAL && OF
+   depends on (ARCH_HISI && CPU_THERMAL && OF) || COMPILE_TEST
help
  Enable this to plug hisilicon's thermal sensor driver into the Linux
  thermal framework. cpufreq is used as the cooling device to throttle
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 02/10] thermal: spear: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to spear driver to facilitate
maintenance.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Viresh Kumar 
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f2b1d31..0334886 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -182,7 +182,7 @@ config IMX_THERMAL
 
 config SPEAR_THERMAL
bool "SPEAr thermal sensor driver"
-   depends on PLAT_SPEAR
+   depends on PLAT_SPEAR || COMPILE_TEST
depends on OF
help
  Enable this to plug the SPEAr thermal sensor driver into the Linux
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 04/10] thermal: kirkwood: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to kirkwood driver to facilitate
maintenance.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2e0aaee..f1da24e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -208,7 +208,7 @@ config RCAR_THERMAL
 
 config KIRKWOOD_THERMAL
tristate "Temperature sensor on Marvell Kirkwood SoCs"
-   depends on MACH_KIRKWOOD
+   depends on MACH_KIRKWOOD || COMPILE_TEST
depends on OF
help
  Support for the Kirkwood thermal sensor driver into the Linux thermal
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 07/10] thermal: exynos: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to exynos driver to facilitate
maintenance.

Cc: Lukasz Majewski 
Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index c2c8cba..202905e8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -345,7 +345,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig"
 endmenu
 
 menu "Samsung thermal drivers"
-depends on ARCH_EXYNOS
+depends on ARCH_EXYNOS || COMPILE_TEST
 source "drivers/thermal/samsung/Kconfig"
 endmenu
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 05/10] thermal: dove: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to dove driver to facilitate
maintenance.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f1da24e..b38ce41 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -216,7 +216,7 @@ config KIRKWOOD_THERMAL
 
 config DOVE_THERMAL
tristate "Temperature sensor on Marvell Dove SoCs"
-   depends on ARCH_DOVE || MACH_DOVE
+   depends on ARCH_DOVE || MACH_DOVE || COMPILE_TEST
depends on OF
help
  Support for the Dove thermal sensor driver in the Linux thermal
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 03/10] thermal: rockchip: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to rockchip driver to facilitate
maintenance.

Cc: Zhang Rui 
Cc: Heiko Stuebner 
Cc: linux...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 0334886..2e0aaee 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -190,7 +190,7 @@ config SPEAR_THERMAL
 
 config ROCKCHIP_THERMAL
tristate "Rockchip thermal driver"
-   depends on ARCH_ROCKCHIP
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
depends on RESET_CONTROLLER
help
  Rockchip thermal driver provides support for Temperature sensor
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 09/10] thermal: ti-soc: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to ti-soc driver to facilitate
maintenance.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/ti-soc-thermal/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/Kconfig 
b/drivers/thermal/ti-soc-thermal/Kconfig
index bd4c7be..7a24018 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -1,7 +1,7 @@
 config TI_SOC_THERMAL
tristate "Texas Instruments SoCs temperature sensor driver"
depends on THERMAL
-   depends on ARCH_HAS_BANDGAP
+   depends on ARCH_HAS_BANDGAP || COMPILE_TEST
help
  If you say yes here you get support for the Texas Instruments
  OMAP4460+ on die bandgap temperature sensor support. The register
@@ -24,7 +24,7 @@ config TI_THERMAL
 config OMAP4_THERMAL
bool "Texas Instruments OMAP4 thermal support"
depends on TI_SOC_THERMAL
-   depends on ARCH_OMAP4
+   depends on ARCH_OMAP4 || COMPILE_TEST
help
  If you say yes here you get thermal support for the Texas Instruments
  OMAP4 SoC family. The current chip supported are:
@@ -38,7 +38,7 @@ config OMAP4_THERMAL
 config OMAP5_THERMAL
bool "Texas Instruments OMAP5 thermal support"
depends on TI_SOC_THERMAL
-   depends on SOC_OMAP5
+   depends on SOC_OMAP5 || COMPILE_TEST
help
  If you say yes here you get thermal support for the Texas Instruments
  OMAP5 SoC family. The current chip supported are:
@@ -50,7 +50,7 @@ config OMAP5_THERMAL
 config DRA752_THERMAL
bool "Texas Instruments DRA752 thermal support"
depends on TI_SOC_THERMAL
-   depends on SOC_DRA7XX
+   depends on SOC_DRA7XX || COMPILE_TEST
help
  If you say yes here you get thermal support for the Texas Instruments
  DRA752 SoC family. The current chip supported are:
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 08/10] thermal: qcom_spmi: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to qcom_spmi driver to facilitate
maintenance.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 202905e8..63b46c0 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -356,7 +356,7 @@ endmenu
 
 config QCOM_SPMI_TEMP_ALARM
tristate "Qualcomm SPMI PMIC Temperature Alarm"
-   depends on OF && SPMI && IIO
+   depends on OF && (SPMI || COMPILE_TEST) && IIO
select REGMAP_SPMI
help
  This enables a thermal sysfs driver for Qualcomm plug-and-play (QPNP)
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 06/10] thermal: armada: allow compile test

[Eduardo Valentin]

Adding COMPILE_TEST flag to armada driver to facilitate
maintenance.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b38ce41..c2c8cba 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -234,7 +234,7 @@ config DB8500_THERMAL
 
 config ARMADA_THERMAL
tristate "Armada 370/XP thermal management"
-   depends on ARCH_MVEBU
+   depends on ARCH_MVEBU || COMPILE_TEST
depends on OF
help
  Enable this option if you want to have support for thermal management
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 10/10] thermal: ti-soc: Kconfig fix to avoid menu showing wrongly

[Eduardo Valentin]

Move the dependencies to menu, so we avoid showing it wrongly.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig| 1 +
 drivers/thermal/ti-soc-thermal/Kconfig | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 63b46c0..9453553 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -341,6 +341,7 @@ config ACPI_THERMAL_REL
depends on ACPI
 
 menu "Texas Instruments thermal drivers"
+depends on ARCH_HAS_BANDGAP || COMPILE_TEST
 source "drivers/thermal/ti-soc-thermal/Kconfig"
 endmenu
 
diff --git a/drivers/thermal/ti-soc-thermal/Kconfig 
b/drivers/thermal/ti-soc-thermal/Kconfig
index 7a24018..cb6686f 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -1,7 +1,5 @@
 config TI_SOC_THERMAL
tristate "Texas Instruments SoCs temperature sensor driver"
-   depends on THERMAL
-   depends on ARCH_HAS_BANDGAP || COMPILE_TEST
help
  If you say yes here you get support for the Texas Instruments
  OMAP4460+ on die bandgap temperature sensor support. The register
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

[Alex Deucher]

On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary  wrote:
> Hello,
> I have a PC Chips A31G board with AGPro slot and found that nouveau does not
> work properly with it. Console works but reverts to software mode, X11 hangs
> with mouse cursor only.
>
> The slot is physically AGP 1.5V but is wired to PCI bus as the chipset (SiS
> 761) does not support AGP cards. To further complicate things, the chipset has
> AGP capability - but only for the integrated video. You can see that in the
> lspci output below - the AGP card is on bus 0 and SiS card on bus 1 (AGP bus
> behind the AGP bridge). The SiS card is not used (can be disabled in BIOS but
> it does not improve things - as the AGP capability of the host bridge remains
> active).
>
> As seen in dmesg below, kernel tries to set AGP 8x mode for all AGP devices,
> including the AGP 4x TNT2 card which is not even connected to the AGP bridge.
>
> Setting nouveau.agpmode=0 makes it work but how can we make this case work
> automatically?
>
> Radeon driver does some "ring test" and if it fails, it disables AGP mode and
> retries. That seems to work a bit (with R7000 but not with R7200).

You can boot with radeon.agpmode=-1 to force pci mode.

Alex

>
> But I think that we shouldn't even touch the AGP registers of other devices
> in this case as it might break the integrated video.
> But how can we know that the card is connected to the AGP bus? There does not
> seem to be a reliable way...
>
> dmesg:
> [   22.015411] nouveau  [  DEVICE][:00:05.0] BOOT0  : 0x20154000
> [   22.015473] nouveau  [  DEVICE][:00:05.0] Chipset: NV05 (NV05)
> [   22.015527] nouveau  [  DEVICE][:00:05.0] Family : NV04
> [   22.041131] nouveau  [   VBIOS][:00:05.0] using image from PRAMIN
> [   22.041194] nouveau  [   VBIOS][:00:05.0] BMP version 5.6
> [   22.041382] nouveau  [   VBIOS][:00:05.0] version 02.05.20.02.00
> [   22.041561] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.041867] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.042079] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.042133] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.042245] nouveau W[  PTIMER][:00:05.0] unknown input clock freq
> [   22.042306] nouveau  [ PFB][:00:05.0] RAM type: SDRAM
> [   22.042360] nouveau  [ PFB][:00:05.0] RAM size: 32 MiB
> [   22.042413] nouveau  [ PFB][:00:05.0]ZCOMP: 0 tags
> [   22.047063] nouveau  [ CLK][:00:05.0] --:
> [   22.047137] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.047220] agpgart-amd64 :00:00.0: AGP 3.0 bridge
> [   22.047281] agpgart: systemd-udevd tried to set rate=x12. Setting to AGP3 
> x8 mode.
> [   22.047348] agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode
> [   22.047425] nouveau :00:05.0: putting AGP V3 device into 8x mode
> [   22.047503] pci :01:00.0: putting AGP V3 device into 8x mode
> [   22.047632] [TTM] Zone  kernel: Available graphics memory: 239112 kiB
> [   22.047685] [TTM] Initializing pool allocator
> [   22.047744] [TTM] Initializing DMA pool allocator
> [   22.047814] nouveau  [ DRM] VRAM: 31 MiB
> [   22.047865] nouveau  [ DRM] GART: 64 MiB
> [   22.047918] nouveau  [ DRM] BMP version 5.6
> [   22.047971] nouveau W[ DRM] No DCB data found in VBIOS
> [   22.051250] nouveau  [ DRM] Saving VGA fonts
> [   22.099912] nouveau W[ DRM] No DCB data found in VBIOS
> [   22.101006] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   22.101061] [drm] Driver supports precise vblank timestamp query.
> [   22.102645] nouveau  [ DRM] MM: using M2MF for buffer copies
> [   22.133344] nouveau  [ DRM] allocated 1280x1024 fb: 0x4000, bo db2d6c00
> [   22.133545] fbcon: nouveaufb (fb0) is primary device
> [   22.369387] nouveau E[ DRM] GPU lockup - switching to software fbcon
> [   22.378443] Console: switching to colour frame buffer device 160x64
> [   22.395704] nouveau :00:05.0: fb0: nouveaufb frame buffer device
> [   22.395808] nouveau :00:05.0: registered panic notifier
> [   22.396783] [drm] Initialized nouveau 1.2.2 20120801 for :00:05.0 on 
> minor 0
>
> lspci -vvnn:
> 00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 761/M761 Host 
> [1039:0761] (rev 01)
> Subsystem: Elitegroup Computer Systems Device [1019:0131]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 32
> Region 0: Memory at f000 (32-bit, non-prefetchable) [size=64M]
> Capabilities: [a0] AGP version 3.0
> Status: RQ=32 Iso- ArqSz=2 Cal=3 SBA+ ITACoh- GART64- HTrans- 
> 64bit- FW- AGP3+ Rate=x4,x8
> Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- 
> Rate=x8
> Capabilities: [d0] HyperTransport: Slave or Primary 

Re: [PATCH] platform-msi: Do not cache msi_desc in handler_data

[Jiang Liu]

On 2015/9/13 20:37, Marc Zyngier wrote:
> The current implementation of platform MSI caches the msi_desc
> pointer in irq_data::handler_data. This is a bit silly, as
> we also have irq_data::msi_desc, which is perfectly valid.
> 
> Remove the useless assignment and simplify the whole flow.
> 
> Reported-by: Ma Jun 
> Signed-off-by: Marc Zyngier 
Reviewed-by: Jiang Liu 



> ---
>  drivers/base/platform-msi.c | 18 +++---
>  1 file changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
> index 1857a5d..134483d 100644
> --- a/drivers/base/platform-msi.c
> +++ b/drivers/base/platform-msi.c
> @@ -63,20 +63,8 @@ static int platform_msi_init(struct irq_domain *domain,
>unsigned int virq, irq_hw_number_t hwirq,
>msi_alloc_info_t *arg)
>  {
> - struct irq_data *data;
> -
> - irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> -   info->chip, info->chip_data);
> -
> - /*
> -  * Save the MSI descriptor in handler_data so that the
> -  * irq_write_msi_msg callback can retrieve it (and the
> -  * associated device).
> -  */
> - data = irq_domain_get_irq_data(domain, virq);
> - data->handler_data = arg->desc;
> -
> - return 0;
> + return irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> +  info->chip, info->chip_data);
>  }
>  #else
>  #define platform_msi_set_descNULL
> @@ -97,7 +85,7 @@ static void platform_msi_update_dom_ops(struct 
> msi_domain_info *info)
>  
>  static void platform_msi_write_msg(struct irq_data *data, struct msi_msg 
> *msg)
>  {
> - struct msi_desc *desc = irq_data_get_irq_handler_data(data);
> + struct msi_desc *desc = irq_data_get_msi_desc(data);
>   struct platform_msi_priv_data *priv_data;
>  
>   priv_data = desc->platform.msi_priv_data;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] CMA: fix CONFIG_CMA_SIZE_MBYTES overflow in 64bit

[Tan Xiaojun]

Hi, please review and give some suggestions.

Any suggestion by anyone is fine to me.

Thanks
Xiaojun

On 2015/9/7 12:21, Tan Xiaojun wrote:
> In 64bit system, if you set CONFIG_CMA_SIZE_MBYTES>=2048, it will
> overflow and size_bytes will be a big wrong number.
> 
> Set CONFIG_CMA_SIZE_MBYTES=2048 and you will get an info below
> during system boot:
> 
> *
> cma: Failed to reserve 17592186042368 MiB
> *
> 
> Signed-off-by: Tan Xiaojun 
> ---
>  drivers/base/dma-contiguous.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index 950fff9..426ba27 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
> @@ -46,7 +46,7 @@ struct cma *dma_contiguous_default_area;
>   * Users, who want to set the size of global CMA area for their system
>   * should use cma= kernel parameter.
>   */
> -static const phys_addr_t size_bytes = CMA_SIZE_MBYTES * SZ_1M;
> +static const phys_addr_t size_bytes = (phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;
>  static phys_addr_t size_cmdline = -1;
>  static phys_addr_t base_cmdline;
>  static phys_addr_t limit_cmdline;
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 4.3-rc1 build error on CentOS 5.11 "scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory"

[Dongsheng Yang]

On 09/12/2015 07:22 AM, Davidlohr Bueso wrote:

On Fri, 11 Sep 2015, Vinson Lee wrote:


Hi.

With the latest Linux 4.3-rc1, I am hitting this build error on CentOS
5.11.

 HOSTCC  scripts/sign-file
scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or
directory
#include 


fwiw/rant, I have run into kernel build issues recently due to lack of
openssl libs.
The solution is trivial, in my case just intalling my distros openssl-devel
package,


Even I install-ed the openssl-devel, I can compile it but I met a
problem in `make modules_install`

At main.c:178:
- SSL error:02001002:system library:fopen:No such file or directory: 
bss_file.c:169

- SSL error:2006D080:BIO routines:BIO_new_file:no such file: bss_file.c:172
sign-file: : No such file or directory


but this will probably break things for more people. And this
is with default
configs... annoying.

Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Use (two) different compilers at build-time?

[Fengguang Wu]

On Sun, Sep 13, 2015 at 05:21:41PM +0200, Sedat Dilek wrote:
> On Thu, Sep 10, 2015 at 2:25 AM, Fengguang Wu  wrote:
> > On Mon, Sep 07, 2015 at 09:12:58PM +0200, Sedat Dilek wrote:
> >> Hi,
> >>
> >> is it possible to use a different compiler at build-time?
> >
> > btw, it'd be great if clang can just work on mainline kernel.
> >
> 
> I am not a member of that LLVMLinux team, but they upstreamed a lot of 
> patches.
> 
> > I tried to run clang in 0day kbuild tests, however make aborts
> > quickly in seconds. There are dozens of clang patches provided in
> >
> > http://llvm.linuxfoundation.org/index.php/Main_Page
> >
> > however such our-of-tree patches are not bisect friendly.
> >
> 
> I agree, there is a high potential for improvements in LLVMLinux :-).
> 
> Unfortunately, I struggled here some days with $COMPILER's
> inline-optimization (disable | force| noinline) and it turned out to
> be a "known" x86-hweight issue (a patch was archived and thrown away
> from the series of x86 patches).
> 
> Finally, I have a "buildable" and "running-on-bare-metal"
> llvmlinux-patched Linux v4.2 here on Ubuntu/precise AMD64.

That's great!

> It is everytime interesting to see where the root cause sits.
> It's like in everyday life - never assume - just ask - stay curious
> and attentive :-).

If upstream kernels can just work (at least work for one kconfig),
I'll be able to follow up add run regular 0day build tests for LLVM.
Which should guarantee new break ups are detected ASAP and hopefully
the developer that breaks it may help fix it up "automatically". :-)

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 15/17] thermal: st: allow compile test

[Eduardo Valentin]

On Fri, Sep 11, 2015 at 10:23:35AM +0100, Lee Jones wrote:
> On Wed, 09 Sep 2015, Eduardo Valentin wrote:
> 
> > Adding COMPILE_TEST flag to st driver to facilitate
> > maintenance.
> > 
> > Cc: Zhang Rui 
> > Cc: Nicolas Boichat 
> > Cc: Mark Brown 
> > Cc: Fabian Frederick 
> > Cc: Wolfram Sang 
> > Cc: Lee Jones 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Eduardo Valentin 
> > ---
> >  drivers/thermal/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Sounds reasonable.
> 
> So long as it's been tested and nothing breaks:
> 
> Acked-by: Lee Jones 

Thanks for the review. But now checking the compilation test using bfin
as target, I see several compilation issues.

So, I am leaving this one out for now. It requires further changes.

BR,

> 
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index 9069cc7..d94b4e9 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -350,7 +350,7 @@ source "drivers/thermal/samsung/Kconfig"
> >  endmenu
> >  
> >  menu "STMicroelectronics thermal drivers"
> > -depends on ARCH_STI && OF
> > +depends on (ARCH_STI || COMPILE_TEST) && OF
> >  source "drivers/thermal/st/Kconfig"
> >  endmenu
> >  
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog


signature.asc
Description: Digital signature

[PATCH V2] kasan: use IS_ALIGNED in memory_is_poisoned_8()

[Xishi Qiu]

Use IS_ALIGNED() to determine whether the shadow span two bytes.
It generates less code and more readable. Add some comments in 
shadow check functions.

Please apply "kasan: fix last shadow judgement in memory_is_poisoned_16()"
first.

Signed-off-by: Xishi Qiu 
---
 mm/kasan/kasan.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 8da2114..00d5605 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -86,6 +86,10 @@ static __always_inline bool memory_is_poisoned_2(unsigned 
long addr)
if (memory_is_poisoned_1(addr + 1))
return true;
 
+   /*
+* If the shadow spans two bytes, the first byte should
+* be zero.
+*/
if (likely(((addr + 1) & KASAN_SHADOW_MASK) != 0))
return false;
 
@@ -103,6 +107,10 @@ static __always_inline bool memory_is_poisoned_4(unsigned 
long addr)
if (memory_is_poisoned_1(addr + 3))
return true;
 
+   /*
+* If the shadow spans two bytes, the first byte should
+* be zero.
+*/
if (likely(((addr + 3) & KASAN_SHADOW_MASK) >= 3))
return false;
 
@@ -120,7 +128,11 @@ static __always_inline bool memory_is_poisoned_8(unsigned 
long addr)
if (memory_is_poisoned_1(addr + 7))
return true;
 
-   if (likely(((addr + 7) & KASAN_SHADOW_MASK) >= 7))
+   /*
+* If the shadow spans two bytes, the first byte should
+* be zero.
+*/
+   if (likely(IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
return false;
 
return unlikely(*(u8 *)shadow_addr);
@@ -139,7 +151,12 @@ static __always_inline bool memory_is_poisoned_16(unsigned 
long addr)
if (unlikely(shadow_first_bytes))
return true;
 
-   if (likely(IS_ALIGNED(addr, 8)))
+   /*
+* If the shadow spans three bytes, we should continue to
+* check the last byte. The first two bytes which we
+* checked above should always be zero.
+*/
+   if (likely(IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
return false;
 
return memory_is_poisoned_1(addr + 15);
-- 
2.0.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] misc: add CS2000 Fractional-N driver

[Kuninori Morimoto]

Hi Arnd

Thank you for your feedback

> > From: Kuninori Morimoto 
> > 
> > This patch adds CS2000 Fractional-N driver as clock provider.
> > It is useful if it supports runtime clock setting, but it supports
> > fixed clock rate at this point.
> > 
> > Signed-off-by: Kuninori Morimoto 
> > ---
> >  .../devicetree/bindings/misc/cs2000-cp.txt |  20 ++
> >  drivers/misc/Kconfig   |   6 +
> >  drivers/misc/Makefile  |   1 +
> >  drivers/misc/cs2000-cp.c   | 341 
> > +
> >  4 files changed, 368 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/misc/cs2000-cp.txt
> >  create mode 100644 drivers/misc/cs2000-cp.c
> 
> I think the driver should be in drivers/clk/ if it provides a clk to
> other devices.
> 
> Please also split out the binding document into a separate patch and
> Cc the devicetree mailing list.

OK, thanks
I will do it, and send to clock ML

> > +   ret = cs2000_get_clk(client, _in, _out);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   ret = cs2000_enable_dev_config(client);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   ret = cs2000_clk_in_bound_rate(client, rate_in);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   ret = cs2000_ratio_set(client, ch, rate_in, rate_out);
> > +   if (ret < 0)
> > +   return ret;
> 
> The probe function lacks unwinding if anything goes wrong, so you end
> up with clocks that are registered but the driver being absent.
> For most things, you can use the devm_*() interfaces here.

I got it.
Thanks

Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 3/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC

[chenfeng]

On 2015/9/11 16:41, Arnd Bergmann wrote:
> On Friday 11 September 2015 16:18:38 Chen Feng wrote:
>> +static int __init hi6220_reset_init(void)
>> +{
>> +int ret;
>> +struct device_node *np;
>> +struct hi6220_reset_data *data;
>> +
>> +data = kzalloc(sizeof(*data), GFP_KERNEL);
>> +if (!data)
>> +return -ENOMEM;
>> +
>> +np = of_find_compatible_node(NULL, NULL, "hisilicon,hi6220_reset_ctl");
>> +if (!np) {
>> +ret = -ENXIO;
>> +goto err_alloc;
>> +}
> 
> Why is this not a platform driver?
> 
OK,I will change this to a platform driver.

>> +if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
>> +reset_controller_register(>rc_dev);
>> +
>> +return 0;
> 
> The Kconfig symbol already depends on RESET_CONTROLLER, so
> the IS_ENABLED() check looks redundant.
> 
Yes,agree with you.
>   Arnd
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 3/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC

[chenfeng]

On 2015/9/12 14:06, xuyiping wrote:
> 
> 
> On 2015/9/11 16:18, Chen Feng wrote:
>> Add reset driver for hi6220-hikey board,this driver supply deassert
>> of IP. on hi6220 SoC.
>>
>> Signed-off-by: Chen Feng 
>> ---
>>   drivers/reset/Kconfig  |   1 +
>>   drivers/reset/Makefile |   1 +
>>   drivers/reset/hisilicon/Kconfig|   5 ++
>>   drivers/reset/hisilicon/Makefile   |   1 +
>>   drivers/reset/hisilicon/hi6220_reset.c | 118 
>> +
>>   5 files changed, 126 insertions(+)
>>   create mode 100644 drivers/reset/hisilicon/Kconfig
>>   create mode 100644 drivers/reset/hisilicon/Makefile
>>   create mode 100644 drivers/reset/hisilicon/hi6220_reset.c
>>
>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
>> index 0615f50..df37212 100644
>> --- a/drivers/reset/Kconfig
>> +++ b/drivers/reset/Kconfig
>> @@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
>> If unsure, say no.
>>
>>   source "drivers/reset/sti/Kconfig"
>> +source "drivers/reset/hisilicon/Kconfig"
>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>> index 157d421..331d7b2 100644
>> --- a/drivers/reset/Makefile
>> +++ b/drivers/reset/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>>   obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
>>   obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>>   obj-$(CONFIG_ARCH_STI) += sti/
>> +obj-$(CONFIG_ARCH_HISI) += hisilicon/
>> diff --git a/drivers/reset/hisilicon/Kconfig 
>> b/drivers/reset/hisilicon/Kconfig
>> new file mode 100644
>> index 000..26bf95a
>> --- /dev/null
>> +++ b/drivers/reset/hisilicon/Kconfig
>> @@ -0,0 +1,5 @@
>> +config COMMON_RESET_HI6220
>> +tristate "Hi6220 Reset Driver"
>> +depends on (ARCH_HISI && RESET_CONTROLLER)
>> +help
>> +  Build the Hisilicon Hi6220 reset driver.
>> diff --git a/drivers/reset/hisilicon/Makefile 
>> b/drivers/reset/hisilicon/Makefile
>> new file mode 100644
>> index 000..c932f86
>> --- /dev/null
>> +++ b/drivers/reset/hisilicon/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
>> diff --git a/drivers/reset/hisilicon/hi6220_reset.c 
>> b/drivers/reset/hisilicon/hi6220_reset.c
>> new file mode 100644
>> index 000..097133d
>> --- /dev/null
>> +++ b/drivers/reset/hisilicon/hi6220_reset.c
>> @@ -0,0 +1,118 @@
>> +/*
>> + * Hisilicon Hi6220 reset controller driver
>> + *
>> + * Copyright (c) 2015 Hisilicon Limited.
>> + *
>> + * Author: Feng Chen 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define ASSET_OFFSET0x300
>> +#define DEASSET_OFFSET  0x304
>> +
>> +struct hi6220_reset_data {
>> +spinlock_treset_lock; /*device spin-lock*/
>> +void __iomem*src_base;
>> +void __iomem*asset_base;
>> +void __iomem*deasset_base;
>> +struct reset_controller_devrc_dev;
>> +};
>> +
>> +static int hi6220_reset_assert(struct reset_controller_dev *rc_dev,
>> +   unsigned long idx)
>> +{
>> +struct hi6220_reset_data *data = container_of(rc_dev,
>> +struct hi6220_reset_data,
>> +rc_dev);
>> +
>> +unsigned long flags;
>> +int bank = idx >> 8;
>> +int offset = idx & 0xff;
>> +
>> +spin_lock_irqsave(>reset_lock, flags);
> 
> the spin_lock looks useless.
> 
> it is not a "read and write" register.
> 
>> +writel(BIT(offset), data->asset_base + (bank * 0x10));
>> +
>> +spin_unlock_irqrestore(>reset_lock, flags);
>> +
>> +return 0;
>> +}
>> +
>> +static int hi6220_reset_deassert(struct reset_controller_dev *rc_dev,
>> + unsigned long idx)
>> +{
>> +struct hi6220_reset_data *data = container_of(rc_dev,
>> +struct hi6220_reset_data,
>> +rc_dev);
>> +
>> +unsigned long flags;
>> +int bank = idx >> 8;
>> +int offset = idx & 0xff;
> 
> no need to check the idx scope ?
> 
Yes, I think this has already been checked at reset framework.
>> +spin_lock_irqsave(>reset_lock, flags);
>> +
>> +writel(BIT(offset), data->deasset_base + (bank * 0x10));
>> +
>> +spin_unlock_irqrestore(>reset_lock, flags);
>> +
>> +return 0;
>> +}
>> +
>> +static struct reset_control_ops hi6220_reset_ops = {
>> +.assert = hi6220_reset_assert,
>> +.deassert = hi6220_reset_deassert,
>> +};
>> +
>> +static int __init hi6220_reset_init(void)
>> +{
>> +int ret;
>> +struct device_node *np;
>> +struct hi6220_reset_data *data;
>> +
>> +data = kzalloc(sizeof(*data), GFP_KERNEL);
>> +if (!data)
>> +return -ENOMEM;
>> +
>> +np = of_find_compatible_node(NULL, NULL, 

[PATCH v9 5/5] QE: Move QE from arch/powerpc to drivers/soc

[Zhao Qiang]

ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
Changes for v4:
- move drivers/soc/fsl-qe to drivers/soc/fsl/qe
- move head files for qe from include/linux/fsl to include/soc/fsl
- move qe_ic.c to drivers/irqchip/
Changes for v5:
- update MAINTAINERS
Changes for v6:
- rebase
Changes for v7:
- move this patch from 2/3 to 3/3
Changes for v8:
- Nil 
Changes for v9:
- Nil 

 MAINTAINERS|  5 ++--
 arch/powerpc/platforms/83xx/km83xx.c   |  4 +--
 arch/powerpc/platforms/83xx/misc.c |  2 +-
 arch/powerpc/platforms/83xx/mpc832x_mds.c  |  4 +--
 arch/powerpc/platforms/83xx/mpc832x_rdb.c  |  4 +--
 arch/powerpc/platforms/83xx/mpc836x_mds.c  |  4 +--
 arch/powerpc/platforms/83xx/mpc836x_rdk.c  |  4 +--
 arch/powerpc/platforms/85xx/common.c   |  2 +-
 arch/powerpc/platforms/85xx/corenet_generic.c  |  2 +-
 arch/powerpc/platforms/85xx/mpc85xx_mds.c  |  4 +--
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c  |  4 +--
 arch/powerpc/platforms/85xx/twr_p102x.c|  4 +--
 arch/powerpc/platforms/Kconfig | 20 -
 arch/powerpc/sysdev/cpm_common.c   |  2 +-
 arch/powerpc/sysdev/qe_lib/Kconfig | 22 ---
 arch/powerpc/sysdev/qe_lib/Makefile|  6 +---
 arch/powerpc/sysdev/qe_lib/gpio.c  |  2 +-
 arch/powerpc/sysdev/qe_lib/qe_io.c |  2 +-
 arch/powerpc/sysdev/qe_lib/usb.c   |  4 +--
 drivers/irqchip/Makefile   |  1 +
 .../sysdev/qe_lib => drivers/irqchip}/qe_ic.c  |  2 +-
 .../sysdev/qe_lib => drivers/irqchip}/qe_ic.h  |  4 +--
 drivers/net/ethernet/freescale/fsl_pq_mdio.c   |  2 +-
 drivers/net/ethernet/freescale/ucc_geth.c  |  8 +++---
 drivers/net/ethernet/freescale/ucc_geth.h  |  8 +++---
 drivers/soc/Kconfig|  1 +
 drivers/soc/Makefile   |  1 +
 drivers/soc/fsl/Makefile   |  5 
 drivers/soc/fsl/qe/Kconfig | 33 ++
 drivers/soc/fsl/qe/Makefile|  9 ++
 .../sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c  |  4 +--
 .../qe_lib => drivers/soc/fsl/qe}/qe_common.c  |  2 +-
 .../sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c |  6 ++--
 .../qe_lib => drivers/soc/fsl/qe}/ucc_fast.c   |  8 +++---
 .../qe_lib => drivers/soc/fsl/qe}/ucc_slow.c   |  8 +++---
 drivers/spi/spi-fsl-cpm.c  |  2 +-
 drivers/tty/serial/ucc_uart.c  |  2 +-
 drivers/usb/gadget/udc/fsl_qe_udc.c|  2 +-
 drivers/usb/host/fhci-hcd.c|  2 +-
 drivers/usb/host/fhci-hub.c|  2 +-
 drivers/usb/host/fhci-sched.c  |  2 +-
 drivers/usb/host/fhci.h|  4 +--
 .../include/asm => include/linux/fsl/qe}/qe_ic.h   |  0
 .../include/asm => include/soc/fsl/qe}/immap_qe.h  |  0
 .../include/asm => include/soc/fsl/qe}/qe.h|  2 +-
 .../include/asm => include/soc/fsl/qe}/ucc.h   |  4 +--
 .../include/asm => include/soc/fsl/qe}/ucc_fast.h  |  6 ++--
 .../include/asm => include/soc/fsl/qe}/ucc_slow.h  |  6 ++--
 48 files changed, 127 insertions(+), 110 deletions(-)
 rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.c (99%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.h (97%)
 create mode 100644 drivers/soc/fsl/Makefile
 create mode 100644 drivers/soc/fsl/qe/Kconfig
 create mode 100644 drivers/soc/fsl/qe/Makefile
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c (99%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe_common.c (99%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c (98%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_fast.c (98%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_slow.c (98%)
 rename {arch/powerpc/include/asm => include/linux/fsl/qe}/qe_ic.h (100%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/immap_qe.h (100%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/qe.h (99%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/ucc.h (96%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/ucc_fast.h (98%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/ucc_slow.h (99%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 562ae4e..c688e61 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4155,8 +4155,9 @@ F:include/linux/fs_enet_pd.h
 FREESCALE QUICC ENGINE LIBRARY
 L: linuxppc-...@lists.ozlabs.org
 S: Orphan
-F: 

[PATCH v9 4/5] CPM: modify cpm_muram_* functions

[Zhao Qiang]

CPM and QE have the same muram, shared the same
muram management functions. Delete cpm_muram_* functions,
using qe_muram_*.

Signed-off-by: Zhao Qiang 
---
Changes for v9:
- splitted from patch 3/5, modify cpm muram management functions.

 arch/powerpc/include/asm/cpm.h   |  59 
 arch/powerpc/include/asm/qe.h|   8 +++
 arch/powerpc/sysdev/cpm_common.c | 141 +--
 3 files changed, 9 insertions(+), 199 deletions(-)

diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
index 4398a6c..003a736 100644
--- a/arch/powerpc/include/asm/cpm.h
+++ b/arch/powerpc/include/asm/cpm.h
@@ -93,22 +93,6 @@ typedef struct cpm_buf_desc {
  */
 
 #define BD_SC_EMPTY(0x8000)/* Receive is empty */
-#define BD_SC_READY(0x8000)/* Transmit is ready */
-#define BD_SC_WRAP (0x2000)/* Last buffer descriptor */
-#define BD_SC_INTRPT   (0x1000)/* Interrupt on change */
-#define BD_SC_LAST (0x0800)/* Last buffer in frame */
-#define BD_SC_TC   (0x0400)/* Transmit CRC */
-#define BD_SC_CM   (0x0200)/* Continuous mode */
-#define BD_SC_ID   (0x0100)/* Rec'd too many idles */
-#define BD_SC_P(0x0100)/* xmt preamble */
-#define BD_SC_BR   (0x0020)/* Break received */
-#define BD_SC_FR   (0x0010)/* Framing error */
-#define BD_SC_PR   (0x0008)/* Parity error */
-#define BD_SC_NAK  (0x0004)/* NAK - did not respond */
-#define BD_SC_OV   (0x0002)/* Overrun */
-#define BD_SC_UN   (0x0002)/* Underrun */
-#define BD_SC_CD   (0x0001)/* */
-#define BD_SC_CL   (0x0001)/* Collision */
 
 /* Buffer descriptor control/status used by Ethernet receive.
  * Common to SCC and FCC.
@@ -155,49 +139,6 @@ typedef struct cpm_buf_desc {
  */
 #define BD_I2C_START   (0x0400)
 
-int cpm_muram_init(void);
-
-#if defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE)
-unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
-int cpm_muram_free(unsigned long offset);
-unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
-void __iomem *cpm_muram_addr(unsigned long offset);
-unsigned long cpm_muram_offset(void __iomem *addr);
-dma_addr_t cpm_muram_dma(void __iomem *addr);
-#else
-static inline unsigned long cpm_muram_alloc(unsigned long size,
-   unsigned long align)
-{
-   return -ENOSYS;
-}
-
-static inline int cpm_muram_free(unsigned long offset)
-{
-   return -ENOSYS;
-}
-
-static inline unsigned long cpm_muram_alloc_fixed(unsigned long offset,
- unsigned long size)
-{
-   return -ENOSYS;
-}
-
-static inline void __iomem *cpm_muram_addr(unsigned long offset)
-{
-   return NULL;
-}
-
-static inline unsigned long cpm_muram_offset(void __iomem *addr)
-{
-   return -ENOSYS;
-}
-
-static inline dma_addr_t cpm_muram_dma(void __iomem *addr)
-{
-   return 0;
-}
-#endif /* defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE) */
-
 #ifdef CONFIG_CPM
 int cpm_command(u32 command, u8 opcode);
 #else
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 3af9033..aee968f 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -189,6 +189,14 @@ static inline int qe_alive_during_sleep(void)
 #endif
 }
 
+/* we actually use qe_muram implementation, define this for convenience */
+#define cpm_muram_init qe_muram_init
+#define cpm_muram_alloc qe_muram_alloc
+#define cpm_muram_alloc_fixed qe_muram_alloc_fixed
+#define cpm_muram_free qe_muram_free
+#define cpm_muram_addr qe_muram_addr
+#define cpm_muram_offset qe_muram_offset
+
 int qe_muram_init(void);
 
 #if defined(CONFIG_QUICC_ENGINE)
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 4f78695..328c3ec 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -27,8 +27,8 @@
 
 #include 
 #include 
-#include 
 #include 
+#include 
 
 #include 
 
@@ -65,151 +65,12 @@ void __init udbg_init_cpm(void)
 }
 #endif
 
-static spinlock_t cpm_muram_lock;
-static rh_block_t cpm_boot_muram_rh_block[16];
-static rh_info_t cpm_muram_info;
 static u8 __iomem *muram_vbase;
 static phys_addr_t muram_pbase;
 
 /* Max address size we deal with */
 #define OF_MAX_ADDR_CELLS  4
 
-int cpm_muram_init(void)
-{
-   struct device_node *np;
-   struct resource r;
-   u32 zero[OF_MAX_ADDR_CELLS] = {};
-   resource_size_t max = 0;
-   int i = 0;
-   int ret = 0;
-
-   if (muram_pbase)
-   return 0;
-
-   spin_lock_init(_muram_lock);
-   /* initialize the info header */
-   rh_init(_muram_info, 1,
-   sizeof(cpm_boot_muram_rh_block) /
-   sizeof(cpm_boot_muram_rh_block[0]),
-   cpm_boot_muram_rh_block);
-
-

[PATCH v9 3/5] qe_common: add qe_muram_ functions to manage muram

[Zhao Qiang]

muram is used for qe, add qe_muram_ functions to manage
muram.

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- no changes
Changes for v3:
- no changes
Changes for v4:
- no changes
Changes for v5:
- no changes
Changes for v6:
- using genalloc instead rheap to manage QE MURAM
- remove qe_reset from platform file, using 
- subsys_initcall to call qe_init function.
Changes for v7:
- move this patch from 3/3 to 2/3
- convert cpm with genalloc
- check for gen_pool allocation failure
Changes for v8:
- rebase
- move BD_SC_* macro instead of copy
Changes for v9:
- doesn't modify CPM, add a new patch to modify.
- rebase

 arch/powerpc/include/asm/qe.h |  43 +-
 arch/powerpc/platforms/83xx/km83xx.c  |   2 -
 arch/powerpc/platforms/83xx/mpc832x_mds.c |   2 -
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |   2 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c |   2 -
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |   3 -
 arch/powerpc/platforms/85xx/common.c  |   1 -
 arch/powerpc/platforms/Kconfig|   1 +
 arch/powerpc/sysdev/qe_lib/Makefile   |   2 +-
 arch/powerpc/sysdev/qe_lib/qe.c   |  15 ++
 arch/powerpc/sysdev/qe_lib/qe_common.c| 242 ++
 11 files changed, 294 insertions(+), 21 deletions(-)
 create mode 100644 arch/powerpc/sysdev/qe_lib/qe_common.c

diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 32b9bfa..3af9033 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -16,10 +16,13 @@
 #define _ASM_POWERPC_QE_H
 #ifdef __KERNEL__
 
+#include 
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
+#include 
 #include 
 
 #define QE_NUM_OF_SNUM 256 /* There are 256 serial number in QE */
@@ -186,13 +189,16 @@ static inline int qe_alive_during_sleep(void)
 #endif
 }
 
-/* we actually use cpm_muram implementation, define this for convenience */
-#define qe_muram_init cpm_muram_init
-#define qe_muram_alloc cpm_muram_alloc
-#define qe_muram_alloc_fixed cpm_muram_alloc_fixed
-#define qe_muram_free cpm_muram_free
-#define qe_muram_addr cpm_muram_addr
-#define qe_muram_offset cpm_muram_offset
+int qe_muram_init(void);
+
+#if defined(CONFIG_QUICC_ENGINE)
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align);
+unsigned long qe_muram_alloc_fixed(unsigned long offset, unsigned long size);
+int qe_muram_free(unsigned long offset);
+void __iomem *qe_muram_addr(unsigned long offset);
+unsigned long qe_muram_offset(void __iomem *addr);
+dma_addr_t qe_muram_dma(void __iomem *addr);
+#endif /* defined(CONFIG_QUICC_ENGINE) */
 
 /* Structure that defines QE firmware binary files.
  *
@@ -266,6 +272,27 @@ struct qe_bd {
 #define BD_STATUS_MASK 0x
 #define BD_LENGTH_MASK 0x
 
+/* Buffer descriptor control/status used by serial
+ */
+
+#define BD_SC_EMPTY(0x8000)/* Receive is empty */
+#define BD_SC_READY(0x8000)/* Transmit is ready */
+#define BD_SC_WRAP (0x2000)/* Last buffer descriptor */
+#define BD_SC_INTRPT   (0x1000)/* Interrupt on change */
+#define BD_SC_LAST (0x0800)/* Last buffer in frame */
+#define BD_SC_TC   (0x0400)/* Transmit CRC */
+#define BD_SC_CM   (0x0200)/* Continuous mode */
+#define BD_SC_ID   (0x0100)/* Rec'd too many idles */
+#define BD_SC_P(0x0100)/* xmt preamble */
+#define BD_SC_BR   (0x0020)/* Break received */
+#define BD_SC_FR   (0x0010)/* Framing error */
+#define BD_SC_PR   (0x0008)/* Parity error */
+#define BD_SC_NAK  (0x0004)/* NAK - did not respond */
+#define BD_SC_OV   (0x0002)/* Overrun */
+#define BD_SC_UN   (0x0002)/* Underrun */
+#define BD_SC_CD   (0x0001)/* */
+#define BD_SC_CL   (0x0001)/* Collision */
+
 /* Alignment */
 #define QE_INTR_TABLE_ALIGN16  /* ??? */
 #define QE_ALIGNMENT_OF_BD 8
diff --git a/arch/powerpc/platforms/83xx/km83xx.c 
b/arch/powerpc/platforms/83xx/km83xx.c
index bf4c447..ae111581 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -136,8 +136,6 @@ static void __init mpc83xx_km_setup_arch(void)
mpc83xx_setup_pci();
 
 #ifdef CONFIG_QUICC_ENGINE
-   qe_reset();
-
np = of_find_node_by_name(NULL, "par_io");
if (np != NULL) {
par_io_init(np);
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c 
b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 8d76220..aacc43f 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -74,8 +74,6 @@ static void __init mpc832x_sys_setup_arch(void)
mpc83xx_setup_pci();
 
 #ifdef CONFIG_QUICC_ENGINE
-   qe_reset();
-
if ((np = of_find_node_by_name(NULL, "par_io")) != NULL) {
  

[PATCH v9 2/5] genalloc:support allocating specific region

[Zhao Qiang]

Add new algo for genalloc, it reserve a specific region of
memory matching the size requirement (no alignment constraint)

Signed-off-by: Zhao Qiang 
---
Changes for v9:
- reserve a specific region, if the return region
- is not during the specific region, return fail.

 include/linux/genalloc.h | 11 +++
 lib/genalloc.c   | 30 ++
 2 files changed, 41 insertions(+)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index aaf3dc2..85e3b2f 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -82,6 +82,13 @@ struct genpool_data_align {
int align;  /* alignment by bytes for starting address */
 };
 
+/*
+ *  gen_pool data descriptor for gen_pool_fixed_fit.
+ */
+struct genpool_data_fixed {
+   unsigned long offset;   /* The offset of the specific region */
+};
+
 extern struct gen_pool *gen_pool_create(int, int);
 extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
 extern int gen_pool_add_virt(struct gen_pool *, unsigned long, phys_addr_t,
@@ -121,6 +128,10 @@ extern unsigned long gen_pool_first_fit(unsigned long 
*map, unsigned long size,
unsigned long start, unsigned int nr, void *data,
struct gen_pool *pool);
 
+extern unsigned long gen_pool_fixed_fit(unsigned long *map,
+   unsigned long size, unsigned long start, unsigned int nr,
+   void *data, struct gen_pool *pool);
+
 extern unsigned long gen_pool_first_fit_align(unsigned long *map,
unsigned long size, unsigned long start, unsigned int nr,
void *data, struct gen_pool *pool);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index b8762b1..87a045e 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -554,6 +554,36 @@ unsigned long gen_pool_first_fit_align(unsigned long *map, 
unsigned long size,
 EXPORT_SYMBOL(gen_pool_first_fit_align);
 
 /**
+ * gen_pool_fixed_fit - reserve a specific region of
+ * matching the size requirement (no alignment constraint)
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @data: data for alignment
+ * @pool: pool to get order from
+ */
+unsigned long gen_pool_fixed_fit(unsigned long *map, unsigned long size,
+   unsigned long start, unsigned int nr, void *data,
+   struct gen_pool *pool)
+{
+   struct genpool_data_fixed *fixed_data;
+   int order;
+   unsigned long offset_bit;
+   unsigned long start_bit;
+
+   fixed_data = data;
+   order = pool->min_alloc_order;
+   offset_bit = fixed_data->offset >> order;
+   start_bit = bitmap_find_next_zero_area(map, size,
+   start + offset_bit, nr, 0);
+   if (start_bit != offset_bit)
+   start_bit = size;
+   return start_bit;
+}
+EXPORT_SYMBOL(gen_pool_fixed_fit);
+
+/**
  * gen_pool_first_fit_order_align - find the first available region
  * of memory matching the size requirement. The region will be aligned
  * to the order of the size specified.
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 1/5] genalloc:support memory-allocation with bytes-alignment to genalloc

[Zhao Qiang]

Bytes alignment is required to manage some special RAM,
so add gen_pool_first_fit_align to genalloc,
meanwhile add gen_pool_alloc_data to pass data to
gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)

Signed-off-by: Zhao Qiang 
---
Changes for v6:
- patches set v6 include a new patch because of using 
- genalloc to manage QE MURAM, patch 0001 is the new 
- patch, adding bytes alignment for allocation for use.
Changes for v7:
- cpm muram also need to use genalloc to manage, it has 
  a function to reserve a specific region of muram,
  add offset to genpool_data for start addr to be allocated.
Changes for v8:
- remove supporting reserving a specific region from this patch
  add a new patch to support it.
Changes for v9:
- Nil 

 include/linux/genalloc.h | 24 
 lib/genalloc.c   | 58 +++-
 2 files changed, 73 insertions(+), 9 deletions(-)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1ccaab4..aaf3dc2 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -30,10 +30,12 @@
 #ifndef __GENALLOC_H__
 #define __GENALLOC_H__
 
+#include 
 #include 
 
 struct device;
 struct device_node;
+struct gen_pool;
 
 /**
  * Allocation callback function type definition
@@ -47,7 +49,7 @@ typedef unsigned long (*genpool_algo_t)(unsigned long *map,
unsigned long size,
unsigned long start,
unsigned int nr,
-   void *data);
+   void *data, struct gen_pool *pool);
 
 /*
  *  General purpose special memory pool descriptor.
@@ -73,6 +75,13 @@ struct gen_pool_chunk {
unsigned long bits[0];  /* bitmap for allocating memory chunk */
 };
 
+/*
+ *  gen_pool data descriptor for gen_pool_first_fit_align.
+ */
+struct genpool_data_align {
+   int align;  /* alignment by bytes for starting address */
+};
+
 extern struct gen_pool *gen_pool_create(int, int);
 extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
 extern int gen_pool_add_virt(struct gen_pool *, unsigned long, phys_addr_t,
@@ -96,6 +105,7 @@ static inline int gen_pool_add(struct gen_pool *pool, 
unsigned long addr,
 }
 extern void gen_pool_destroy(struct gen_pool *);
 extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
+extern unsigned long gen_pool_alloc_data(struct gen_pool *, size_t, void 
*data);
 extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
 extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
@@ -108,14 +118,20 @@ extern void gen_pool_set_algo(struct gen_pool *pool, 
genpool_algo_t algo,
void *data);
 
 extern unsigned long gen_pool_first_fit(unsigned long *map, unsigned long size,
-   unsigned long start, unsigned int nr, void *data);
+   unsigned long start, unsigned int nr, void *data,
+   struct gen_pool *pool);
+
+extern unsigned long gen_pool_first_fit_align(unsigned long *map,
+   unsigned long size, unsigned long start, unsigned int nr,
+   void *data, struct gen_pool *pool);
 
 extern unsigned long gen_pool_first_fit_order_align(unsigned long *map,
unsigned long size, unsigned long start, unsigned int nr,
-   void *data);
+   void *data, struct gen_pool *pool);
 
 extern unsigned long gen_pool_best_fit(unsigned long *map, unsigned long size,
-   unsigned long start, unsigned int nr, void *data);
+   unsigned long start, unsigned int nr, void *data,
+   struct gen_pool *pool);
 
 extern struct gen_pool *devm_gen_pool_create(struct device *dev,
int min_alloc_order, int nid);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index d214866..b8762b1 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -269,6 +269,24 @@ EXPORT_SYMBOL(gen_pool_destroy);
  */
 unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
 {
+   return gen_pool_alloc_data(pool, size, pool->data);
+}
+EXPORT_SYMBOL(gen_pool_alloc);
+
+/**
+ * gen_pool_alloc_data - allocate special memory from the pool
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ * @data: data passed to algorithm
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ */
+unsigned long gen_pool_alloc_data(struct gen_pool *pool, size_t size,
+   void *data)
+{
struct gen_pool_chunk *chunk;
unsigned long addr = 0;
int order = pool->min_alloc_order;
@@ -290,7 +308,7 @@ unsigned long gen_pool_alloc(struct gen_pool *pool, size_t 
size)

Re: [PATCH v6 0/6] Altera PCIe host controller driver with MSI support

[Ley Foon Tan]

On Tue, Sep 1, 2015 at 6:40 PM, Marc Zyngier  wrote:
> On 01/09/15 11:30, Ley Foon Tan wrote:
>> This is the 6th version of patch set to add support for Altera PCIe host
>> controller with MSI feature on Altera FPGA device families. This patchset
>> mainly resolve comments from Marc Zyngier in v5 and minor fixes.
>
> The merge window has just started, and I'm not going to go through
> another review at that stage - too many things in flight.
>
> Please ping me again once 4.3-rc1 is out.
>
Hi Marc

Do you have further comment on this patchset?
Thanks.

Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v5 1/2] mfd: update Intel soc PMIC header file to support Broxton WC PMIC

[Zha, Qipeng]

> > >>  
> > >> +#define INIT_REGMAP_IRQ(_irq, _off, _mask)  \
> > >> +[_irq] = { .reg_offset = (_off), .mask = (_mask) }
> > >> +
> > 
> > >No, that's not what I asked.
> > 
> > >Either this macro is going to be useful to *everyone*, or it's probably 
> > >not useful to *anyone*.  If it's going to exist, it should exist in the 
> > >core header file, not Intel's own.
> > 
> > Jones, can we keep current change as for intel's own ?  not sure if Mark 
> > agree to merge this macro to core regmap header file.
> > Maybe some driver want to initialize regmap_irq structure with 
> > different/customed way.
> > Thanks.

> Is that what Mark said when you submitted this to him?

No, I don't get feedback from Mark.

Re: [RFC 00/13] perf_env/CPU socket reorg/fixes

[Wangnan (F)]

On 2015/9/11 21:36, Arnaldo Carvalho de Melo wrote:

Em Fri, Sep 11, 2015 at 10:30:52AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Fri, Sep 11, 2015 at 10:29:37AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Fri, Sep 11, 2015 at 10:03:39AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Fri, Sep 11, 2015 at 08:20:54PM +0800, Wangnan (F) escreveu:

I have tested patch 1 to 10. They looks good to me except patch 4/13. Please

Ok, I'll take that as a Tested-by: you for 1-10 with 4/13 having the
checks added, ok?
  

see my email in that thread.
  

I add those checks.

Ok, below is the diff for adding the checks. The get_{core,socket}_id
functions should be moved to tools/lib/api/cpu.[ch], using the same
interface as cpu__get_max_freq(), using the int return value to
propagate the precise error, etc. Will do it in a follow up patch.

Humm, but then, what happens if a CPU is offline? I'm checking it now...

   # cat /sys/devices/system/cpu/cpu3/topology/core_id
   3
   # cat
   /sys/devices/system/cpu/cpu3/topology/physical_package_id
   0
   # echo 0 > /sys/devices/system/cpu/cpu3/online
   # cat
   /sys/devices/system/cpu/cpu3/topology/physical_package_id
   cat: /sys/devices/system/cpu/cpu3/topology/physical_package_id: No such file 
or directory
   # cat /sys/devices/system/cpu/cpu3/topology/core_id
   cat: /sys/devices/system/cpu/cpu3/topology/core_id: No such file or directory
   #

So we shouldn't check the result, right? We could further validate it by
checking:

   # cat /sys/devices/system/cpu/cpu3/online
   0
   #

But assuming that not being able to access it means it is offline looks
almost reasonable, if not strictly correct, so I'm removing the tests
and will revisit this when I move those functions to
tools/lib/api/cpu.[ch].


I highly suspect that setting 'online' to 0 is not the only reason of
the removal of topology directory. Testing the existance of the two
files should be better.

Thank you.


- Arnaldo


diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
index 6af4f7c36820..2e4cad84197b 100644
--- a/tools/perf/util/env.c
+++ b/tools/perf/util/env.c
@@ -60,7 +60,7 @@ out_enomem:
  
  int perf_env__read_cpu_topology_map(struct perf_env *env)

  {
-   int cpu, nr_cpus;
+   int cpu, nr_cpus, err;
  
  	if (env->cpu != NULL)

return 0;
@@ -77,10 +77,17 @@ int perf_env__read_cpu_topology_map(struct perf_env *env)
return -ENOMEM;
  
  	for (cpu = 0; cpu < nr_cpus; ++cpu) {

-   env->cpu[cpu].core_id= cpu_map__get_core_id(cpu);
-   env->cpu[cpu].socket_id  = cpu_map__get_socket_id(cpu);
+   err = env->cpu[cpu].core_id = cpu_map__get_core_id(cpu);
+   if (err < 0)
+   goto out_free;
+   err = env->cpu[cpu].socket_id = cpu_map__get_socket_id(cpu);
+   if (err < 0)
+   goto out_free;
}
  
-	env->nr_cpus_avail = nr_cpus;

return 0;
+
+out_free:
+   zfree(>cpu);
+   return err;
  }



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Build regressions/improvements in v4.3-rc1

[Guenter Roeck]

Russell,

On 09/13/2015 09:57 AM, Russell King - ARM Linux wrote:

On Sun, Sep 13, 2015 at 08:19:26AM -0700, Guenter Roeck wrote:

arm:rpc_defconfig:

fs/fat/dir.c: In function 'fat_ioctl_filldir':
fs/fat/dir.c:752:43: internal compiler error: Max. number of generated reload 
insns per insn is achieved (90)


Not much can be done about that - gcc people aren't interested in fixing
ARMv3 compiler support anymore, although this is still buildable with
older compilers.  I don't see any point in removing the platform just
because GCC has decided to break itself.


To be fair, they actually fixed a number of similar problems recently,
though I don't know if they happened to fix this one in later versions of gcc.
This specific error seems to be pretty far spread.

Guess you are saying that there is no plan to implement a workaround.
Fair enough; I'll just remove the configuration from my list of tests.


arm64:allmodconfig:

drivers/firmware/qcom_scm-32.c:196:4: error: expected string literal before 
‘__asmeq’
drivers/firmware/qcom_scm-32.c:221:2: error: implicit declaration of function 
‘secure_flush_area’
drivers/firmware/qcom_scm-32.c:239:2: error: implicit declaration of function 
‘outer_inv_range’
drivers/firmware/qcom_scm-32.c:331:4: error: expected string literal before 
‘__asmeq’
drivers/firmware/qcom_scm-32.c:361:4: error: expected string literal before 
‘__asmeq’


This file shouldn't be built on ARM64, and there's a fix in the pipeline
which obviously didn't make -rc1 for it.



Fixes are in the pipeline for most of the problems. Only exception is alpha;
the patches necessary to fix the problems there only met silence.

I'll probably wait for -rc4 or -rc5 and then send a pull request for everything
that is left directly to Linus.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 00/13] perf_env/CPU socket reorg/fixes

[Wangnan (F)]

On 2015/9/11 21:03, Arnaldo Carvalho de Melo wrote:

Em Fri, Sep 11, 2015 at 08:20:54PM +0800, Wangnan (F) escreveu:

I have tested patch 1 to 10. They looks good to me except patch 4/13. Please

Ok, I'll take that as a Tested-by: you for 1-10 with 4/13 having the
checks added, ok?


Sure.

Tested-by: Wang Nan  // for patch 1-10 except 4


see my email in that thread.

I add those checks.
  

However, during the testing I found a limitation related to cpu
online/offline and 'perf top' that, if I offline most of cores before
'perf top', then online them during 'perf top' running, 'perf top'
dooesn't report new CPUs. It still reports the CPUs which are online


  

However, It is relatively a rare case. I don't think we have to fix it
in this patchset.

Yup, unrelated to this patchset. But we need to seamlessly support that
situation, even telling the user that a CPU went offline/online.

- Arnaldo



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kasan: use IS_ALIGNED in memory_is_poisoned_8()

[Xishi Qiu]

On 2015/9/12 6:47, Andrew Morton wrote:

> On Fri, 11 Sep 2015 10:02:29 +0800 Xishi Qiu  wrote:
> 
>> Use IS_ALIGNED() to determine whether the shadow span two bytes.
>> It generates less code and more readable.
>>
> 
> Please cc Andrey Ryabinin on kasan patches.

Sorry, my mistake.

> 
>> --- a/mm/kasan/kasan.c
>> +++ b/mm/kasan/kasan.c
>> @@ -120,7 +120,7 @@ static __always_inline bool 
>> memory_is_poisoned_8(unsigned long addr)
>>  if (memory_is_poisoned_1(addr + 7))
>>  return true;
>>  
>> -if (likely(((addr + 7) & KASAN_SHADOW_MASK) >= 7))
>> +if (likely(IS_ALIGNED(addr, 8)))
>>  return false;
> 
> Wouldn't IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE) be more appropriate?
> 

OK, I'll send V2.

> But I'm not really sure what the original code is trying to do.
> 
>   if ((addr + 7) & 7) >= 7)
> 
> can only evaluate true if ((addr + 7) & 7) equals 7, so the ">=" could
> be "==".
> 

I think it should be "==", the value will not "> 7"

> I think.  The code looks a bit weird.  A code comment would help.
> 
> And how come memory_is_poisoned_16() does IS_ALIGNED(addr, 8)?  Should
> it be 16?

No, it is to determine whether the shadow span two bytes(8 bytes, not 16).

Thanks,
Xishi Qiu

> 
> 
> .
> 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please remove commit 6609b638353c99c5736e05abd17197f1cb776e0e as it makes me feel miserable

[Diego Viola]

On Sun, Sep 13, 2015 at 9:24 PM, Ken Moffat  wrote:
> On Sun, Sep 13, 2015 at 08:06:02PM -0300, Diego Viola wrote:
>> Hello,
>>
>> Can someone please remove this commit from the repo:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/README?id=6609b638353c99c5736e05abd17197f1cb776e0e
>>
>> I made a huge grammar mistake in my commit message that I can't
>> forget, it makes me feel terrible and I can't stop thinking about it.
>>
>> Please rewrite the history for the README or whatever, but just make
>> this commit go away.
>>
>> It should have been spelled as:
>>
>> "README: GTK+ is an acronym"
>>
>> or
>>
>> "README: GTK+ is an initialism"
>>
>> But saying "a acronym" is just wrong.
>>
>> Thanks and sorry about this mistake, English isn't my native language. :-(
>>
>> Diego
>
> If it is any consolation, almost everybody makes mistakes in commit
> messages.  I certainly do, but fortunately many of mine will never
> be public.  As a native English speaker, 'a acronym' is perfectly
> understandable (but 'an initialism' is slightly odd).  But once it
> is committed and made public, it is done.
>
> The content of your change is correct.  Thanks for fixing it.  In
> future, perhaps do what I try to do - for commit messages themselves,
> review before the next commit, and if necessary git commit --amend.
> For email subjects, try to review before sending (I fail on both of
> these).
>
> What's done is done, and the kernel *is* better for your
> contribution.  It is said that in the early days of the kernel there
> was a war between those who could spell and those who could not.
> Please, don't worry about grammar - as long as the text can be
> understood, there is no problem.
>
> ĸen
> --
> Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
>   aka "The hedgehog song"
>

Thanks, that made me feel better. I'll be more careful next time. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the kdbus tree with Linus' tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the kdbus tree got a conflict in:

  tools/testing/selftests/Makefile

between commit:

  b6d973441675 ("selftests: add membarrier syscall test")

from Linus' tree and commit:

  b7270dd9f7d4 ("kdbus: add selftests")

from the kdbus tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc tools/testing/selftests/Makefile
index 89b05ec9,b57100cefb74..
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@@ -4,9 -4,8 +4,10 @@@ TARGETS += efivarf
  TARGETS += exec
  TARGETS += firmware
  TARGETS += ftrace
 +TARGETS += futex
  TARGETS += kcmp
+ TARGETS += kdbus
 +TARGETS += membarrier
  TARGETS += memfd
  TARGETS += memory-hotplug
  TARGETS += mount
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/2] ARM: dts: Add exynos5422-odroidxu4 board

[Krzysztof Kozlowski]

Add Hardkernel Odroid XU4 board Device Tree sources. The board differs
from Odroid XU3 and XU3-Lite by:
1. No green and red LEDs (except standard red power LED).
2. Only two PWM outputs are used (fan and blue LED)
3. No audio codec.
4. Two USB3 ports in host mode (no micro USB3 connector for OTG).
5. Realtek RTL8153-CG gigabit network adapter (instead of SMSC9514).
6. Additional connector with IO ports (I2S_0, I2C_5).
7. No DisplayPort (like XU3-Lite).
8. No TI INA231 power measurement sensors (like XU3-Lite).

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Javier Martinez Canillas 

---

Changes since v2:
1. Rebase on top v2 "ARM: dts: Fix LEDs on exynos5422-odroidxu3"
   https://lkml.org/lkml/2015/9/13/18
   This means that on new Odroid XU4 DTS the PWM outputs are
   already fixed.
2. Add Javier's reviewed-by.

Changes since v1:
1. hsi2c_5 and is20 are disabled on Odroid XU4 (after moving these nodes
   to the audio DTSI).
2. Update Samsung's copyright date for XU4 DTS.
---
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 50 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts| 50 ++
 arch/arm/boot/dts/exynos5422-odroidxu3.dts | 50 ++
 arch/arm/boot/dts/exynos5422-odroidxu4.dts | 48 +
 5 files changed, 150 insertions(+), 49 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu4.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d2eaab..3d27fe34647f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -123,6 +123,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5420-smdk5420.dtb \
exynos5422-odroidxu3.dtb \
exynos5422-odroidxu3-lite.dtb \
+   exynos5422-odroidxu4.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 2f0fb8678e9f..a83d569baea8 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -46,40 +46,6 @@
reset-gpios = < 0 1>;
};
 
-   pwmleds {
-   compatible = "pwm-leds";
-
-   greenled {
-   label = "green:mmc0";
-   pwms = < 1 200 0>;
-   pwm-names = "pwm1";
-   /*
-* Green LED is much brighter than the others
-* so limit its max brightness
-*/
-   max_brightness = <127>;
-   linux,default-trigger = "mmc0";
-   };
-
-   blueled {
-   label = "blue:heartbeat";
-   pwms = < 2 200 0>;
-   pwm-names = "pwm2";
-   max_brightness = <255>;
-   linux,default-trigger = "heartbeat";
-   };
-   };
-
-   gpioleds {
-   compatible = "gpio-leds";
-   redled {
-   label = "red:microSD";
-   gpios = < 3 GPIO_ACTIVE_HIGH>;
-   default-state = "off";
-   linux,default-trigger = "mmc1";
-   };
-   };
-
fan0: pwm-fan {
compatible = "pwm-fan";
pwms = < 0 20972 0>;
@@ -417,18 +383,6 @@
};
 };
 
- {
-   /*
-* PWM 0 -- fan
-* PWM 1 -- Green LED
-* PWM 2 -- Blue LED
-* PWM 3 -- on MIPI connector for backlight
-*/
-   pinctrl-0 = <_out _out _out _out>;
-   pinctrl-names = "default";
-   status = "okay";
-};
-
 _cpu0 {
vtmu-supply = <_reg>;
status = "okay";
@@ -464,9 +418,7 @@
dr_mode = "host";
 };
 
-_dwc3_1 {
-   dr_mode = "otg";
-};
+/* usbdrd_dwc3_1 mode customized in each board */
 
 _0 {
vdd33-supply = <_reg>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 
b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
index 9c0cea99c996..b1b36081f343 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
@@ -18,4 +18,54 @@
 / {
model = "Hardkernel Odroid XU3 Lite";
compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", 
"samsung,exynos5";
+
+   pwmleds {
+   compatible = "pwm-leds";
+
+   greenled {
+   label = "green:mmc0";
+   pwms = < 1 200 0>;
+   pwm-names = "pwm1";
+   /*
+* Green LED is much brighter than the others
+* so limit its max brightness
+*/
+   max_brightness = <127>;
+

[PATCH v3 1/2] ARM: dts: Split audio configuration to separate exynos5422-odroidxu3-audio

[Krzysztof Kozlowski]

The Odroid XU4 board does not have audio codec so before adding DTS for
new board split the audio codec to separate DTSI file. Include the audio codec
DTSI in Odroid XU3 and XU3-Lite boards.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Javier Martinez Canillas 

---
Changes since v2:
1. Add Javier's reviewed-by.

Changes since v1:
1. New patch (refactor).
---
 arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi  | 61 ++
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 47 -
 arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts|  1 +
 arch/arm/boot/dts/exynos5422-odroidxu3.dts |  1 +
 4 files changed, 63 insertions(+), 47 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
new file mode 100644
index ..9493923ec652
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
@@ -0,0 +1,61 @@
+/*
+ * Hardkernel Odroid XU3 Audio Codec device tree source
+ *
+ * Copyright (c) 2015 Krzysztof Kozlowski
+ * Copyright (c) 2014 Collabora Ltd.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+   sound: sound {
+   compatible = "simple-audio-card";
+
+   simple-audio-card,name = "Odroid-XU3";
+   simple-audio-card,widgets =
+   "Headphone", "Headphone Jack",
+   "Speakers", "Speakers";
+   simple-audio-card,routing =
+   "Headphone Jack", "HPL",
+   "Headphone Jack", "HPR",
+   "Headphone Jack", "MICBIAS",
+   "IN1", "Headphone Jack",
+   "Speakers", "SPKL",
+   "Speakers", "SPKR";
+
+   simple-audio-card,format = "i2s";
+   simple-audio-card,bitclock-master = <_codec>;
+   simple-audio-card,frame-master = <_codec>;
+
+   simple-audio-card,cpu {
+   sound-dai = < 0>;
+   system-clock-frequency = <1920>;
+   };
+
+   link0_codec: simple-audio-card,codec {
+   sound-dai = <>;
+   clocks = < CLK_I2S_CDCLK>;
+   };
+   };
+};
+
+_5 {
+   status = "okay";
+   max98090: max98090@10 {
+   compatible = "maxim,max98090";
+   reg = <0x10>;
+   interrupt-parent = <>;
+   interrupts = <2 0>;
+   clocks = < CLK_I2S_CDCLK>;
+   clock-names = "mclk";
+   #sound-dai-cells = <0>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 90d298dce851..2f0fb8678e9f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -80,36 +80,6 @@
};
};
 
-   sound: sound {
-   compatible = "simple-audio-card";
-
-   simple-audio-card,name = "Odroid-XU3";
-   simple-audio-card,widgets =
-   "Headphone", "Headphone Jack",
-   "Speakers", "Speakers";
-   simple-audio-card,routing =
-   "Headphone Jack", "HPL",
-   "Headphone Jack", "HPR",
-   "Headphone Jack", "MICBIAS",
-   "IN1", "Headphone Jack",
-   "Speakers", "SPKL",
-   "Speakers", "SPKR";
-
-   simple-audio-card,format = "i2s";
-   simple-audio-card,bitclock-master = <_codec>;
-   simple-audio-card,frame-master = <_codec>;
-
-   simple-audio-card,cpu {
-   sound-dai = < 0>;
-   system-clock-frequency = <1920>;
-   };
-
-   link0_codec: simple-audio-card,codec {
-   sound-dai = <>;
-   clocks = < CLK_I2S_CDCLK>;
-   };
-   };
-
fan0: pwm-fan {
compatible = "pwm-fan";
pwms = < 0 20972 0>;
@@ -376,19 +346,6 @@
};
 };
 
-_5 {
-   status = "okay";
-   max98090: max98090@10 {
-   compatible = "maxim,max98090";
-   reg = <0x10>;
-   interrupt-parent = <>;
-   interrupts = <2 0>;
-   clocks = < CLK_I2S_CDCLK>;
-   clock-names = "mclk";
-   #sound-dai-cells = <0>;
-   };
-};
-
 _2 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq 

linux-next: stats (Was: Linux 4.3-rc1 - merge window closed)

[Stephen Rothwell]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20150831 was the first linux-next after
the merge window opened.)

Commits in v4.3-rc1 (relative to v4.2):10756
Commits in next-20150831:  10762
Commits with the same SHA1: 9416
Commits with the same patch_id:  673 (1)
Commits with the same subject line:   86 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20150831: 10175 94%

Some breakdown of the list of extra commits (relative to next-20150831)
in -rc1:

Top ten first word of commit summary:

 76 drm
 39 net
 37 ib
 18 perf
 18 ixgbe
 17 cpufreq
 13 input
 12 flow_dissector
 11 ntb
 11 kvm

Top ten authors:

 14 viresh.ku...@linaro.org
 14 trond.mykleb...@primarydata.com
 12 t...@herbertland.com
 12 dan...@iogearbox.net
 11 alexander.deuc...@amd.com
  9 jy0922.s...@samsung.com
  9 bart.vanass...@sandisk.com
  8 ville.syrj...@linux.intel.com
  8 donald.c.skidm...@intel.com
  8 christian.koe...@amd.com

Top ten commiters:

114 da...@davemloft.net
 45 dledf...@redhat.com
 36 rafael.j.wyso...@intel.com
 32 alexander.deuc...@amd.com
 29 torva...@linux-foundation.org
 21 jani.nik...@intel.com
 20 a...@redhat.com
 19 jeffrey.t.kirs...@intel.com
 17 idryo...@gmail.com
 16 trond.mykleb...@primarydata.com

There are also 587 commits in next-20150831 that didn't make it into
v4.3-rc1.  128 are from the kdbus tree and 14 from the orangefs tree
which were not merged by Linus for this release.

Top ten first word of commit summary:

101 kdbus
 52 ib
 40 i2c
 32 arm
 27 mm
 15 selftests
 14 page-flags
 13 orangefs
 13 documentation
 12 parse_integer

Top ten authors:

 66 dh.herrm...@gmail.com
 47 mike.marcinis...@intel.com
 44 a...@linux-foundation.org
 31 ser...@s15v.net
 21 dan...@zonque.org
 16 kirill.shute...@linux.intel.com
 16 adobri...@gmail.com
 13 minc...@kernel.org
 12 wsa+rene...@sang-engineering.com
 12 hub...@omnibond.com

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

The commits by dh.herrm...@gmail.com, ser...@s15v.net and
dan...@zonque.org are all from the kdbus tree and those by
hub...@omnibond.com are all from the orangefs tree.

Top ten commiters:

186 s...@canb.auug.org.au
 77 gre...@linuxfoundation.org
 54 dledf...@redhat.com
 51 dh.herrm...@gmail.com
 43 w...@the-dreams.de
 14 kg...@kernel.org
 11 mathieu.poir...@linaro.org
 10 r...@logtruck.clemson.edu
 10 daniel.vet...@ffwll.ch
  9 paul...@linux.vnet.ibm.com

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

The commits from gre...@linuxfoundation.org and dh.herrm...@gmail.com
are from the kdbus tree and those from r...@logtruck.clemson.edu are
from the orangefs tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity

[Bob Liu]

On 09/14/2015 01:47 AM, Julien Grall wrote:
> 
> 
> On 13/09/2015 13:44, Bob Liu wrote:
>> I may misunderstood here.
>> But I think same changes are also required even if backend supports indirect 
>> grant when frontend is using 64KB page granularity.
>> Else
>> 1) How to set up the grant map for requests in domU?
>> The minimum segment buffer size in a request is PAGE_SIZE(64KB) while grant 
>> is 4KB based.
>>
>> 2) Codes like below in blkback.c may not work correctly?
>> if ((req->u.rw.seg[i].last_sect >= (PAGE_SIZE >> 9)) ||
>>
>> Because PAGE_SIZE in backend is 4KB, while the written value by domU is 64KB 
>> based.
> 
> As mention in my cover letter, this patch is not self-sufficient to support 
> 64KB guest. It's a follow-up of the 64KB page granularity support I sent on 
> the ML (the new version was sent earlier this week [1]).
> 
> One of the patch [2] is taking care of breaking down the I/O request in 
> multiple 4KB segment that will be used in the ring request. You may want to 
> give a look to this patch before looking to this series.
> 

Oh, sorry! I'll have a look at those patches.

Thanks,
-Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please remove commit 6609b638353c99c5736e05abd17197f1cb776e0e as it makes me feel miserable

[Ken Moffat]

On Sun, Sep 13, 2015 at 08:06:02PM -0300, Diego Viola wrote:
> Hello,
> 
> Can someone please remove this commit from the repo:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/README?id=6609b638353c99c5736e05abd17197f1cb776e0e
> 
> I made a huge grammar mistake in my commit message that I can't
> forget, it makes me feel terrible and I can't stop thinking about it.
> 
> Please rewrite the history for the README or whatever, but just make
> this commit go away.
> 
> It should have been spelled as:
> 
> "README: GTK+ is an acronym"
> 
> or
> 
> "README: GTK+ is an initialism"
> 
> But saying "a acronym" is just wrong.
> 
> Thanks and sorry about this mistake, English isn't my native language. :-(
> 
> Diego

If it is any consolation, almost everybody makes mistakes in commit
messages.  I certainly do, but fortunately many of mine will never
be public.  As a native English speaker, 'a acronym' is perfectly
understandable (but 'an initialism' is slightly odd).  But once it
is committed and made public, it is done.

The content of your change is correct.  Thanks for fixing it.  In
future, perhaps do what I try to do - for commit messages themselves,
review before the next commit, and if necessary git commit --amend.
For email subjects, try to review before sending (I fail on both of
these).

What's done is done, and the kernel *is* better for your
contribution.  It is said that in the early days of the kernel there
was a war between those who could spell and those who could not.
Please, don't worry about grammar - as long as the text can be
understood, there is no problem.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka "The hedgehog song"

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the bluetooth tree

[Stephen Rothwell]

Hi Gustavo,

On Mon, 14 Sep 2015 10:14:28 +1000 Stephen Rothwell  
wrote:
>
> I applied the patches that Andrew has had in his post merge series
> (but I think you were sent a rolled up version):

Actually it was sent by Alexander to Marcel:

From: Alexander Aring 
To: mar...@holtmann.org
Cc: Andrew Morton ,
Stephen Rothwell ,
Alexander Aring ,
Stefan Schmidt 
Subject: [PATCH bluetooth-next] drivers/net/ieee802154/at86rf230.c: 
seq_printf() now returns NULL
Date: Fri, 11 Sep 2015 11:23:30 +0200
Message-Id: <1441963410-24844-1-git-send-email-alex.ar...@gmail.com>
X-Mailer: git-send-email 2.5.1

From: Andrew Morton 

I will shortly be sending
http://ozlabs.org/~akpm/mmots/broken-out/fs-seq_file-convert-int-seq_vprint-seq_printf-etc-returns-to-void.patch
to Linus.  This will cause the linux-next version of
drivers/net/ieee802154/at86rf230.c to break at compilation time.

Below is the fix.  I suggest you apply this immediately.

Otherwise I'll try to remember to send this in after Alexander's
890acf8330cac is merged.  But there will be a window during which the
build fails, and we'll get emails...

From: Stephen Rothwell 
Subject: drivers/net/ieee802154/at86rf230.c: seq_printf() now returns NULL

Signed-off-by: Stephen Rothwell 
Cc: Alexander Aring 
Cc: Stefan Schmidt 
Cc: Marcel Holtmann 
Signed-off-by: Andrew Morton 
Signed-off-by: Alexander Aring 
---
 drivers/net/ieee802154/at86rf230.c | 35 ++-
 1 file changed, 10 insertions(+), 25 deletions(-)

diff --git a/drivers/net/ieee802154/at86rf230.c 
b/drivers/net/ieee802154/at86rf230.c
index b8b0628..9756e64 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -1645,32 +1645,17 @@ static struct dentry *at86rf230_debugfs_root;
 static int at86rf230_stats_show(struct seq_file *file, void *offset)
 {
struct at86rf230_local *lp = file->private;
-   int ret;
-
-   ret = seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
-   if (ret < 0)
-   return ret;
-
-   ret = seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
-lp->trac.success_data_pending);
-   if (ret < 0)
-   return ret;
-
-   ret = seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
-lp->trac.success_wait_for_ack);
-   if (ret < 0)
-   return ret;
-
-   ret = seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
-lp->trac.channel_access_failure);
-   if (ret < 0)
-   return ret;
 
-   ret = seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
-   if (ret < 0)
-   return ret;
-
-   return seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
+   seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
+   seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
+  lp->trac.success_data_pending);
+   seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
+  lp->trac.success_wait_for_ack);
+   seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
+  lp->trac.channel_access_failure);
+   seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
+   seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
+   return 0;
 }
 
 static int at86rf230_stats_open(struct inode *inode, struct file *file)
-- 
2.5.1

-- 
Cheers,
Stephen Rothwell
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the bluetooth tree

[Stephen Rothwell]

Hi Gustavo,

After merging the bluetooth tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/net/ieee802154/at86rf230.c: In function 'at86rf230_s
tats_show':
drivers/net/ieee802154/at86rf230.c:1650:6: error: void value not ignored as it 
ought to be
  ret = seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
  ^
drivers/net/ieee802154/at86rf230.c:1654:6: error: void value not ignored as it 
ought to be
  ret = seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
  ^
drivers/net/ieee802154/at86rf230.c:1659:6: error: void value not ignored as it 
ought to be
  ret = seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
  ^
drivers/net/ieee802154/at86rf230.c:1664:6: error: void value not ignored as it 
ought to be
  ret = seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
  ^
drivers/net/ieee802154/at86rf230.c:1669:6: error: void value not ignored as it 
ought to be
  ret = seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
  ^
drivers/net/ieee802154/at86rf230.c:1673:2: error: void value not ignored as it 
ought to be
  return seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
  ^
drivers/net/ieee802154/at86rf230.c:1674:1: warning: control reaches end of 
non-void function [-Wreturn-type]
 }
 ^

Caused by commit

  890acf8330ca ("at86rf230: add debugfs support")

interacting with commit

  6798a8caaf64 ("fs/seq_file: convert int seq_vprint/seq_printf/etc... returns 
to void")

from Linus' tree (as you were warned it would).

I applied the patches that Andrew has had in his post merge series
(but I think you were sent a rolled up version):

From: Stephen Rothwell 
Subject: drivers/net/ieee802154/at86rf230.c: seq_printf() now returns NULL

Signed-off-by: Stephen Rothwell 
Cc: Alexander Aring 
Cc: Stefan Schmidt 
Cc: Marcel Holtmann 
Signed-off-by: Andrew Morton 
---

 drivers/net/ieee802154/at86rf230.c |   28 ++-
 1 file changed, 7 insertions(+), 21 deletions(-)

diff -puN 
drivers/net/ieee802154/at86rf230.c~drivers-net-ieee802154-at86rf230c-seq_printf-now-returns-null
 drivers/net/ieee802154/at86rf230.c
--- 
a/drivers/net/ieee802154/at86rf230.c~drivers-net-ieee802154-at86rf230c-seq_printf-now-returns-null
+++ a/drivers/net/ieee802154/at86rf230.c
@@ -1647,30 +1647,16 @@ static int at86rf230_stats_show(struct s
struct at86rf230_local *lp = file->private;
int ret;
 
-   ret = seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
-   if (ret < 0)
-   return ret;
-
-   ret = seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
+   seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
+   seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
 lp->trac.success_data_pending);
-   if (ret < 0)
-   return ret;
-
-   ret = seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
+   seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
 lp->trac.success_wait_for_ack);
-   if (ret < 0)
-   return ret;
-
-   ret = seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
+   seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
 lp->trac.channel_access_failure);
-   if (ret < 0)
-   return ret;
-
-   ret = seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
-   if (ret < 0)
-   return ret;
-
-   return seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
+   seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
+   seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
+   return 0;
 }
 
 static int at86rf230_stats_open(struct inode *inode, struct file *file)

From: Alexander Aring 
Subject: drivers-net-ieee802154-at86rf230c-seq_printf-now-returns-null-fix
Date: Fri, 11 Sep 2015 11:28:20 -0700

fix whitespace, unused var `ret'

Signed-off-by: Alexander Aring 
Cc: Stephen Rothwell 
Cc: Stefan Schmidt 
Cc: Marcel Holtmann 
Signed-off-by: Andrew Morton 
---

 drivers/net/ieee802154/at86rf230.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff -puN 
drivers/net/ieee802154/at86rf230.c~drivers-net-ieee802154-at86rf230c-seq_printf-now-returns-null-fix
 drivers/net/ieee802154/at86rf230.c
--- 
a/drivers/net/ieee802154/at86rf230.c~drivers-net-ieee802154-at86rf230c-seq_printf-now-returns-null-fix
+++ a/drivers/net/ieee802154/at86rf230.c
@@ -1645,15 +1645,14 @@ static struct dentry *at86rf230_debugfs_
 static int at86rf230_stats_show(struct seq_file *file, void *offset)
 {
struct at86rf230_local *lp = file->private;
-   int ret;
 
seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
-lp->trac.success_data_pending);
+  lp->trac.success_data_pending);
seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
-lp->trac.success_wait_for_ack);
+  

[PATCH v5 10/10] ASoC: rockchip_i2s: modify DMA max burst to 1

[Shawn Lin]

From: Yiwei Cai 

Test with command -
arecord -D hw:0,0 /tmp/a.wav, there are the error dump:
dma-pl330 ffb2.dma-controller: fill_queue:2251 Bad Desc(7)

This error is happening when no a multiple of burst size * burst
length are coming in. The root cause is pl330 dma controller on
Rockchips' platform cannot support DMAFLUSHP instruction which make
dma to flush the req of non-aligned or non-multiple of what we set
before. The saftest way is to set dma max burst to 1.

Signed-off-by: Yiwei Cai 
Fixes: 4495c89fc ("ASoC: add driver for Rockchip RK3xxx I2S")
Signed-off-by: Shawn Lin 
cc: Addy Ke 
cc: Jianqun Xu 
cc: Heiko Stuebner 
cc: Olof Johansson 
cc: Doug Anderson 
cc: Sonny Rao 
cc: Mark Brown 

---

Changes in v5:
- use switch statement for dma_quirk's manipulation

Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None

 sound/soc/rockchip/rockchip_i2s.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index acb5be5..543d0c0 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -23,6 +23,8 @@
 
 #define DRV_NAME "rockchip-i2s"
 
+#define ROCKCHIP_I2S_BROKEN_BURST_LEN (1<<0) /* broken burst len */
+
 struct rk_i2s_dev {
struct device *dev;
 
@@ -418,6 +420,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
struct rk_i2s_dev *i2s;
struct resource *res;
void __iomem *regs;
+   int dma_quirk;
int ret;
 
i2s = devm_kzalloc(>dev, sizeof(*i2s), GFP_KERNEL);
@@ -489,6 +492,24 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
goto err_pcm_register;
}
 
+   dma_quirk = snd_dmaengine_pcm_get_quirks(>dev);
+   switch (dma_quirk) {
+   case ROCKCHIP_I2S_BROKEN_BURST_LEN:
+   /*
+* Unfortunately, we find broken burst len here,
+* just have to limit maxburst to ONE in order to avoid
+* non-multiple burst len access fail the dmaengine if
+* it can't support flush peripheral function.
+*/
+   i2s->playback_dma_data.maxburst = 1;
+   i2s->capture_dma_data.maxburst = 1;
+   break;
+   default:
+   dev_info(>dev, "Default no dma_quirk!\n");
+   break;
+   }
+
return 0;
 
 err_pcm_register:
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] userfaultfd: add missing mmput() in error path

[Eric Biggers]

Signed-off-by: Eric Biggers 
---
 fs/userfaultfd.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 634e676..f9aeb40 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -1287,8 +1287,10 @@ static struct file *userfaultfd_file_create(int flags)
 
file = anon_inode_getfile("[userfaultfd]", _fops, ctx,
  O_RDWR | (flags & UFFD_SHARED_FCNTL_FLAGS));
-   if (IS_ERR(file))
+   if (IS_ERR(file)) {
+   mmput(ctx->mm);
kmem_cache_free(userfaultfd_ctx_cachep, ctx);
+   }
 out:
return file;
 }
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: bad base of the h8300 tree

[Stephen Rothwell]

Hi Yoshinori,

On Tue, 1 Sep 2015 07:40:33 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 31 Aug 2015 07:43:04 +1000 Stephen Rothwell  
> wrote:
> >
> > The h8300 tree today has been based on linux-next.  This cannto work.
> > Please rebase this onto Linus' tree (or some other stable base).
> > 
> > I cannot use your tree in this state, so it will be dropped from
> > linux-next until it is fixed.  Also, Linus cannot pull it in this state.
> 
> And now your tree conatins lots and lots of very old commits that do
> not even have Signed-off-by tags :-(.  The version I have been using
> has a HEAD of commit:
> 
> 99bcfda85f66 "Revert "asm-generic: {get,put}_user ptr argument evaluate only 
> 1 time""
> 
> (which, it turns out" also has no Signed-off-by :-()
> 
> Maybe you should reset your tree to that and try to move on from there.

Can you please clean this up ...

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 08/10] spi: rockchip: modify DMA max burst to 1

[Shawn Lin]

From: Addy Ke 

Generic dma controller on Rockchips' platform cannot support
DMAFLUSHP instruction which make dma to flush the req of non-aligned
or non-multiple of what we need. That will cause an unrecoverable
dma bus error. The saftest way is to set dma max burst to 1.

Signed-off-by: Addy ke 
Fixes: 64e36824b32b06 ("spi/rockchip: add driver for Rockchip...")
Signed-off-by: Shawn Lin 
cc: Heiko Stuebner 
cc: Olof Johansson 
cc: Doug Anderson 
cc: Sonny Rao 
Acked-by: Mark Brown 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None

 drivers/spi/spi-rockchip.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 68e7efe..89dd3d8 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -199,6 +199,8 @@ struct rockchip_spi {
struct sg_table rx_sg;
struct rockchip_spi_dma_data dma_rx;
struct rockchip_spi_dma_data dma_tx;
+   int dma_quirk;
+#define ROCKCHIP_SPI_BROKEN_BURST_LEN (1<<0) /* broken burst len*/
 };
 
 static inline void spi_enable_chip(struct rockchip_spi *rs, int enable)
@@ -449,7 +451,10 @@ static void rockchip_spi_prepare_dma(struct rockchip_spi 
*rs)
rxconf.direction = rs->dma_rx.direction;
rxconf.src_addr = rs->dma_rx.addr;
rxconf.src_addr_width = rs->n_bytes;
-   rxconf.src_maxburst = rs->n_bytes;
+   if (rs->dma_quirk == ROCKCHIP_SPI_BROKEN_BURST_LEN)
+   rxconf.src_maxburst = 1;
+   else
+   rxconf.src_maxburst = 4;
dmaengine_slave_config(rs->dma_rx.ch, );
 
rxdesc = dmaengine_prep_slave_sg(
@@ -466,7 +471,10 @@ static void rockchip_spi_prepare_dma(struct rockchip_spi 
*rs)
txconf.direction = rs->dma_tx.direction;
txconf.dst_addr = rs->dma_tx.addr;
txconf.dst_addr_width = rs->n_bytes;
-   txconf.dst_maxburst = rs->n_bytes;
+   if (rs->dma_quirk == ROCKCHIP_SPI_BROKEN_BURST_LEN)
+   txconf.dst_maxburst = 1;
+   else
+   txconf.dst_maxburst = 4;
dmaengine_slave_config(rs->dma_tx.ch, );
 
txdesc = dmaengine_prep_slave_sg(
@@ -731,6 +739,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
}
 
if (rs->dma_tx.ch && rs->dma_rx.ch) {
+   rs->dma_quirk = dmaengine_get_quirks(rs->dma_rx.ch);
rs->dma_tx.addr = (dma_addr_t)(mem->start + ROCKCHIP_SPI_TXDR);
rs->dma_rx.addr = (dma_addr_t)(mem->start + ROCKCHIP_SPI_RXDR);
rs->dma_tx.direction = DMA_MEM_TO_DEV;
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 09/10] snd: dmaengine-pcm: add snd_dmaengine_pcm_get_quirks interface

[Shawn Lin]

Add snd_dmaengine_pcm_get_quirks for I2S devices to query
dma controller's quirks if they need it to make special workaround
due to broken dma controller design

Signed-off-by: Shawn Lin 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None

 sound/soc/soc-generic-dmaengine-pcm.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/sound/soc/soc-generic-dmaengine-pcm.c 
b/sound/soc/soc-generic-dmaengine-pcm.c
index 6fd1906..42136005 100644
--- a/sound/soc/soc-generic-dmaengine-pcm.c
+++ b/sound/soc/soc-generic-dmaengine-pcm.c
@@ -466,4 +466,28 @@ void snd_dmaengine_pcm_unregister(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_unregister);
 
+
+/**
+ * snd_dmaengine_pcm_get_quirks - Get dmaengine quirks based PCM device
+ * @dev: Parent device the PCM was register with
+ */
+int snd_dmaengine_pcm_get_quirks(struct device *dev)
+{
+   struct snd_soc_platform *platform;
+   struct dmaengine_pcm *pcm;
+   int ret = -ENODEV;
+
+   platform = snd_soc_lookup_platform(dev);
+   if (!platform)
+   return ret;
+
+   pcm = soc_platform_to_pcm(platform);
+
+   if (pcm->chan)
+   ret = dmaengine_get_quirks(pcm->chan[0]);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_get_quirks);
+
 MODULE_LICENSE("GPL");
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 07/10] DMA: pl330: implement dmaengine_get_quirks hook

[Shawn Lin]

By adding this function, slave device can query quirks
from pl330 if they need special settings for dmaengine.

Signed-off-by: Shawn Lin 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None

 drivers/dma/pl330.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 3b9b426..bf01d24 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2156,6 +2156,14 @@ static int pl330_config(struct dma_chan *chan,
return 0;
 }
 
+static int pl330_quirks(struct dma_chan *chan)
+{
+   struct dma_pl330_chan *pch = to_pchan(chan);
+   struct pl330_dmac *pl330 = pch->dmac;
+
+   return pl330->quirks;
+}
+
 static int pl330_terminate_all(struct dma_chan *chan)
 {
struct dma_pl330_chan *pch = to_pchan(chan);
@@ -2928,6 +2936,7 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
pd->device_tx_status = pl330_tx_status;
pd->device_prep_slave_sg = pl330_prep_slave_sg;
pd->device_config = pl330_config;
+   pd->device_get_quirks = pl330_quirks;
pd->device_pause = pl330_pause;
pd->device_terminate_all = pl330_terminate_all;
pd->device_issue_pending = pl330_issue_pending;
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk

[Shawn Lin]

Add dmaengine_get_quirks API for peripheral devices to query
quirks if they need it to make special workaround due to broken
dma controller design.

Signed-off-by: Shawn Lin 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None

 include/linux/dmaengine.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index e2f5eb4..5174ca4 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -704,6 +704,7 @@ struct dma_device {
 
int (*device_config)(struct dma_chan *chan,
 struct dma_slave_config *config);
+   int (*device_get_quirks)(struct dma_chan *chan);
int (*device_pause)(struct dma_chan *chan);
int (*device_resume)(struct dma_chan *chan);
int (*device_terminate_all)(struct dma_chan *chan);
@@ -723,6 +724,14 @@ static inline int dmaengine_slave_config(struct dma_chan 
*chan,
return -ENOSYS;
 }
 
+static inline int dmaengine_get_quirks(struct dma_chan *chan)
+{
+   if (chan->device->device_get_quirks)
+   return chan->device->device_get_quirks(chan);
+
+   return -ENOSYS;
+}
+
 static inline bool is_slave_direction(enum dma_transfer_direction direction)
 {
return (direction == DMA_MEM_TO_DEV) || (direction == DMA_DEV_TO_MEM);
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 05/10] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3xxx platform

[Shawn Lin]

Pl330 integrated in rk3xxx platform doesn't support
DMAFLUSHP function. So we add arm,pl330-broken-no-flushp quirk
for it.

Signed-off-by: Shawn Lin 
cc: Heiko Stuebner 
cc: Doug Anderson 
cc: Olof Johansson 

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
  by Krzysztof.

 arch/arm/boot/dts/rk3xxx.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index a2ae9f3..a8ca4b3 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -79,6 +79,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMA1>;
clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
};
 
dmac1_ns: dma-controller@2001c000 {
@@ -89,6 +90,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMA1>;
clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
status = "disabled";
};
 
@@ -100,6 +102,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMA2>;
clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
};
};
 
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 04/10] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3288 platform

[Shawn Lin]

From: Addy Ke 

Pl330 integrated in rk3288 platform doesn't support
DMAFLUSHP function. So we add arm,pl330-broken-no-flushp quirk
for it.

Signed-off-by: Addy Ke 
Signed-off-by: Shawn Lin 
cc: Heiko Stuebner 
cc: Olof Johansson 
cc: Sonny Rao 

Reviewed-by: Doug Anderson 
Reviewed-by: Sonny Rao 
---

Changes in v5: None
Changes in v4: None
Changes in v3:
- add Reviewed-by: Sonny Rao 

Changes in v2:
- amend the author
- add Reviewed-by: Doug Anderson 
- amend Olof's mail address

Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
  by Krzysztof.
- remove Sunny's tag

 arch/arm/boot/dts/rk3288.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 22316d0..106adf7 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -144,6 +144,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMAC2>;
clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
};
 
dmac_bus_ns: dma-controller@ff60 {
@@ -155,6 +156,7 @@
clocks = < ACLK_DMAC1>;
clock-names = "apb_pclk";
status = "disabled";
+   arm,pl330-broken-no-flushp;
};
 
dmac_bus_s: dma-controller@ffb2 {
@@ -165,6 +167,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMAC1>;
clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
};
};
 
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 03/10] DMA: pl330: add quirk for broken no flushp

[Shawn Lin]

From: Addy Ke 

This patch add "arm,pl330-broken-no-flushp" quirk to avoid execute
DMAFLUSHP if Soc doesn't support it.

Signed-off-by: Addy Ke 
Signed-off-by: Shawn Lin 
cc: Doug Anderson 
cc: Heiko Stuebner 
cc: Olof Johansson 

Reviewed-by: Sonny Rao 
---

Changes in v5: None
Changes in v4: None
Changes in v3:
- add Reviewed-by: Sonny Rao 

Changes in v2:
- amend the author
- fix Olof's mail address

Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
  by Krzysztof.
- remove Sunny's tag

 drivers/dma/pl330.c | 87 ++---
 1 file changed, 62 insertions(+), 25 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 0d544d2..3b9b426 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -34,6 +34,8 @@
 #define PL330_MAX_IRQS 32
 #define PL330_MAX_PERI 32
 
+#define PL330_QUIRK_BROKEN_NO_FLUSHP BIT(0)
+
 enum pl330_cachectrl {
CCTRL0, /* Noncacheable and nonbufferable */
CCTRL1, /* Bufferable only */
@@ -488,6 +490,17 @@ struct pl330_dmac {
/* Peripheral channels connected to this DMAC */
unsigned int num_peripherals;
struct dma_pl330_chan *peripherals; /* keep at end */
+   int quirks;
+};
+
+static struct pl330_of_quirks {
+   char *quirk;
+   int id;
+} of_quirks[] = {
+   {
+   .quirk = "arm,pl330-broken-no-flushp",
+   .id = PL330_QUIRK_BROKEN_NO_FLUSHP,
+   }
 };
 
 struct dma_pl330_desc {
@@ -1137,53 +1150,68 @@ static inline int _ldst_memtomem(unsigned dry_run, u8 
buf[],
return off;
 }
 
-static inline int _ldst_devtomem(unsigned dry_run, u8 buf[],
-   const struct _xfer_spec *pxs, int cyc)
+static inline int _ldst_devtomem(struct pl330_dmac *pl330, unsigned dry_run,
+u8 buf[], const struct _xfer_spec *pxs,
+int cyc)
 {
int off = 0;
enum pl330_cond cond;
 
-   cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
+   if (pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP)
+   cond = BURST;
+   else
+   cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
 
while (cyc--) {
off += _emit_WFP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_LDP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_ST(dry_run, [off], ALWAYS);
-   off += _emit_FLUSHP(dry_run, [off], pxs->desc->peri);
+
+   if (!(pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP))
+   off += _emit_FLUSHP(dry_run, [off],
+   pxs->desc->peri);
}
 
return off;
 }
 
-static inline int _ldst_memtodev(unsigned dry_run, u8 buf[],
-   const struct _xfer_spec *pxs, int cyc)
+static inline int _ldst_memtodev(struct pl330_dmac *pl330,
+unsigned dry_run, u8 buf[],
+const struct _xfer_spec *pxs, int cyc)
 {
int off = 0;
enum pl330_cond cond;
 
-   cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
+   if (pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP)
+   cond = BURST;
+   else
+   cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
+
 
while (cyc--) {
off += _emit_WFP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_LD(dry_run, [off], ALWAYS);
off += _emit_STP(dry_run, [off], cond, pxs->desc->peri);
-   off += _emit_FLUSHP(dry_run, [off], pxs->desc->peri);
+
+   if (!(pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP))
+   off += _emit_FLUSHP(dry_run, [off],
+   pxs->desc->peri);
}
 
return off;
 }
 
-static int _bursts(unsigned dry_run, u8 buf[],
+static int _bursts(struct pl330_dmac *pl330, unsigned dry_run, u8 buf[],
const struct _xfer_spec *pxs, int cyc)
 {
int off = 0;
 
switch (pxs->desc->rqtype) {
case DMA_MEM_TO_DEV:
-   off += _ldst_memtodev(dry_run, [off], pxs, cyc);
+   off += _ldst_memtodev(pl330, dry_run, [off], pxs, cyc);
break;
case DMA_DEV_TO_MEM:
-   off += _ldst_devtomem(dry_run, [off], pxs, cyc);
+   off += _ldst_devtomem(pl330, dry_run, [off], pxs, cyc);
break;
case DMA_MEM_TO_MEM:
off += _ldst_memtomem(dry_run, [off], pxs, cyc);
@@ -1197,7 +1225,7 @@ static int _bursts(unsigned dry_run, u8 buf[],
 }
 
 /* Returns bytes consumed and updates bursts */
-static inline int _loop(unsigned dry_run, u8 buf[],
+static inline int _loop(struct pl330_dmac *pl330, unsigned dry_run, u8 buf[],
unsigned long *bursts, const struct _xfer_spec *pxs)
 {
int cyc, cycmax, szlp, 

[PATCH v5 01/10] DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit

[Shawn Lin]

From: Boojin Kim 

This patch adds to support burst mode for dev-to-mem and
mem-to-dev transmit.

Signed-off-by: Boojin Kim 
Signed-off-by: Addy Ke 
Signed-off-by: Shawn Lin 
cc: Heiko Stuebner 
cc: Doug Anderson 
cc: Olof Johansson 

Reviewed-by: Sonny Rao 
---

Changes in v5:
- add Mark's tag for spi changes
- remove unnecessary whitespace change
- use switch statement for i2s quirk

Changes in v4:
- remove spi & i2s dts changes and query quirk from dmaengine API
  suggeseted by Mark.
- fix typo
- Add dmaengine_get_quirk hook and implement it for pl330

Changes in v3:
- add Sunny's tag
- add more rockchip drivers' changes in this patchset

Changes in v2:
- amend the author
- reorder the patches suggested by Doug
- add Reviewed-by: Doug Anderson  for
  rk3288.dtsi patch and arm-pl330.txt patch

Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
  by Krzysztof.
- add From original author.
- remove Sunny's tag

 drivers/dma/pl330.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index ecab4ea0..0d544d2 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1141,10 +1141,13 @@ static inline int _ldst_devtomem(unsigned dry_run, u8 
buf[],
const struct _xfer_spec *pxs, int cyc)
 {
int off = 0;
+   enum pl330_cond cond;
+
+   cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
 
while (cyc--) {
-   off += _emit_WFP(dry_run, [off], SINGLE, pxs->desc->peri);
-   off += _emit_LDP(dry_run, [off], SINGLE, pxs->desc->peri);
+   off += _emit_WFP(dry_run, [off], cond, pxs->desc->peri);
+   off += _emit_LDP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_ST(dry_run, [off], ALWAYS);
off += _emit_FLUSHP(dry_run, [off], pxs->desc->peri);
}
@@ -1156,11 +1159,14 @@ static inline int _ldst_memtodev(unsigned dry_run, u8 
buf[],
const struct _xfer_spec *pxs, int cyc)
 {
int off = 0;
+   enum pl330_cond cond;
+
+   cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
 
while (cyc--) {
-   off += _emit_WFP(dry_run, [off], SINGLE, pxs->desc->peri);
+   off += _emit_WFP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_LD(dry_run, [off], ALWAYS);
-   off += _emit_STP(dry_run, [off], SINGLE, pxs->desc->peri);
+   off += _emit_STP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_FLUSHP(dry_run, [off], pxs->desc->peri);
}
 
@@ -2557,7 +2563,7 @@ static struct dma_async_tx_descriptor 
*pl330_prep_dma_cyclic(
 
desc->rqtype = direction;
desc->rqcfg.brst_size = pch->burst_sz;
-   desc->rqcfg.brst_len = 1;
+   desc->rqcfg.brst_len = pch->burst_len;
desc->bytes_requested = period_len;
fill_px(>px, dst, src, period_len);
 
@@ -2702,7 +2708,7 @@ pl330_prep_slave_sg(struct dma_chan *chan, struct 
scatterlist *sgl,
}
 
desc->rqcfg.brst_size = pch->burst_sz;
-   desc->rqcfg.brst_len = 1;
+   desc->rqcfg.brst_len = pch->burst_len;
desc->rqtype = direction;
desc->bytes_requested = sg_dma_len(sg);
}
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 02/10] Documentation: arm-pl330: add description of arm,pl330-broken-no-flushp

[Shawn Lin]

Signed-off-by: Shawn Lin 

Reviewed-by: Doug Anderson 
Reviewed-by: Sonny Rao 
---

Changes in v5: None
Changes in v4: None
Changes in v3:
- add Reviewed-by: Sonny Rao 

Changes in v2:
- add Reviewed-by: Doug Anderson 

Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
  by Krzysztof.

 Documentation/devicetree/bindings/dma/arm-pl330.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt 
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
index 2675658..db7e226 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -15,6 +15,7 @@ Optional properties:
 cells in the dmas property of client device.
   - dma-channels: contains the total number of DMA channels supported by the 
DMAC
   - dma-requests: contains the total number of DMA requests supported by the 
DMAC
+  - arm,pl330-broken-no-flushp: quirk for avoiding to execute DMAFLUSHP
 
 Example:
 
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 0/10] Fix broken DMAFLUSHP on Rockchips platform

[Shawn Lin]

The purpose of the DMAFLUSHP instruction:
- Tell the peripheral to clear its status and control registers.
- Send a message to the peripheral to resend its level status.

There are 3 timings described in PL330 Technical Reference Manual:
- Timing 1: Burst request, can work well without DMAFLUSHP.
- Timing 2: Single and burst request, DMAC will ignore the single
transfer request. This timing happens if there are single
and burst request.
- Timing 3: Single transfers for a burst request, DMAC should signals
datype to request the peripheral to flush the contents of
any control registers. This timing happens if there is
not enough MFIFO to places the burst data.

A peripheral may signal a DMA request during the execution of
DMAFLUSHP instruction, that cause DMA request being ignored by DMAC.

But DMAC and all peripherals on RK3X SoCs DO NOT support DMAFLUSHP.
It can't send a message to the peripheral to resend DMA request,
and the peripheral can't acknowledge a flush request from DMAC.
So all DMA requests should NOT be ignored by DMAC, and DMAC will not
notify the peripheral to flush.

To fix this problem, we need:
- Do NOT execute DMAFLUSHP instruction.
- Timing 2 and timing 3 should not happen.

Because on RK3X SoCs, there are 6 or below  channels and 32 MFIFO depth
for DMAC_BUS, and 8 channels and 64 MFIFO depth for DMAC_PERI, it is
impossible to hit the timing 3 if burst length is equal or less than 4.

Since the request type signal by the peripheral can only be set by
software. We can set Rockchip Soc's GRF_PERIDMAC_CON0[2:1] to select single
or burst request, if it is set b01,  all of the peripharals will signal a brust
request. So the timing 2 will not happen, too.

So DMAC on RK3X can support single or burst transfer, but can't support
mixed transfer.

Because burst transfer is more efficient than single transfer, this is
confirmed by our ASIC team, who strongly suggest to use burst transfer.
And this is confirmed by Addy's test on RK3288-Pink2 board, the speed of
spi flash burst transfer will increase about two times than single transfer.
Also, I have tested dw_mmc with pl330 on RK3188 platform to double confirm
the result. That means burst transfer is reansonable.

So we need a quirk not to execute DMAFLUSHP instruction and to use burst
transfer.

Note:
- The Rockchip Soc default value of GRF_PERIDMAC_CON0[2:1] is b01. To
  support brust transfer, these bits should not be changed in bootloader.


Changes in v5:
- add Mark's tag for spi changes
- remove unnecessary whitespace change
- use switch statement for I2S dma_quirk's manipulation

Changes in v4:
- remove spi & i2s dts changes and query quirk from dmaengine API
  suggeseted by Mark.
- fix typo
- Add dmaengine_get_quirk hook and implement it for pl330

Changes in v3:
- add Sunny's tag
- add more rockchip drivers' changes in this patchset
- add Reviewed-by: Sonny Rao 

Changes in v2:
- amend the author
- reorder the patches suggested by Doug
- add Reviewed-by: Doug Anderson  for
  rk3288.dtsi patch and arm-pl330.txt patch
- amend Olof's mail address

Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
  by Krzysztof.
- add From original author.
- remove Sunny's tag

Addy Ke (3):
  DMA: pl330: add quirk for broken no flushp
  ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3288 platform
  spi: rockchip: modify DMA max burst to 1

Boojin Kim (1):
  DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit

Shawn Lin (5):
  Documentation: arm-pl330: add description of
arm,pl330-broken-no-flushp
  ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3xxx platform
  dmaengine: add API for getting dma controller's quirk
  DMA: pl330: implement dmaengine_get_quirks hook
  snd: dmaengine-pcm: add snd_dmaengine_pcm_get_quirks interface

Yiwei Cai (1):
  ASoC: rockchip_i2s: modify DMA max burst to 1

 .../devicetree/bindings/dma/arm-pl330.txt  |   1 +
 arch/arm/boot/dts/rk3288.dtsi  |   3 +
 arch/arm/boot/dts/rk3xxx.dtsi  |   3 +
 drivers/dma/pl330.c| 110 +++--
 drivers/spi/spi-rockchip.c |  13 ++-
 include/linux/dmaengine.h  |   9 ++
 sound/soc/rockchip/rockchip_i2s.c  |  21 
 sound/soc/soc-generic-dmaengine-pcm.c  |  24 +
 8 files changed, 153 insertions(+), 31 deletions(-)

-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()

[Dave Chinner]

On Sat, Sep 12, 2015 at 07:00:27PM -0400, Chris Mason wrote:
> On Fri, Sep 11, 2015 at 04:36:39PM -0700, Linus Torvalds wrote:
> > On Fri, Sep 11, 2015 at 4:16 PM, Chris Mason  wrote:
> > >
> > > For 4.3 timeframes, what runs do you want to see numbers for:
> > >
> > > 1) revert
> > > 2) my hack
> > > 3) plug over multiple sbs (on different devices)
> > > 4) ?
> > 
> > Just 2 or 3.
> > 
> > I don't think the plain revert is all that interesting, and I think
> > the "anything else" is far too late for this merge window.
> 
> I did the plain revert as well, just to have a baseline.  This box is a
> little different from Dave's.   Bare metal two socket box (E5-2660 v2 @
> 2.20Ghz) with 144GB of ram.  I have two pcie flash devices, one nvme and
> one fusionio, and I put a one FS on each device (two mounts total).
> 
> The test created 1.6M files, 4K each.  I used Dave's fs_mark command
> line, spread out over 16 directories from each mounted filesystem.  In
> btrfs they are spread over subvolumes to cut down lock contention.
> 
> I need to change around the dirty ratios more to smooth out the IO, and
> I had trouble with both XFS and btrfs getting runs that were not CPU
> bound.  I included the time to run sync at the end of the run because
> the results were not very consistent without it.
> 
> The XFS runs generally had one CPU pegged at 100%, and I think this is
> throwing off the results.  On Monday I'll redo them with two (four?)
> filesystems per flash device, hopefully that'll break things up.
> 
> The btrfs runs generally had all the CPUs pegged at 100%.  I switched to
> mount -o nodatasum and squeezed out an extra 50K files/sec at much lower
> CPU utilization.
> 
>wall time  fs_mark files/secbytes written/sec
> 
> XFS:
> baseline v4.2:  5m6s   118,578  272MB/s
> Dave's patch:   4m46s  151,421  294MB/s
> my hack:5m5s   150,714  275MB/s
> Linus plug: 5m15s  147,735  266MB/s
> 
> 
> Btrfs (nodatasum):
> baseline v4.2:  4m39s  242,643  313MB/s   
> Dave's patch:   3m46s  252,452  389MB/s
> my hack:3m48s  257,924  379MB/s
> Linus plug: 3m58s  247,528  369MB/s

Really need to run these numbers on slower disks where block layer
merging makes a difference to performance. The high level plugging
improves performance on spinning disks by a huge amount on XFS
because the merging reduces the number of IOs issued to disk by 2
orders of magnitude. Plugging makes comparitively little difference
on devices that can sustain extremely high IOPS and hence sink the
tens to hundreds of thousand individual 4k IOs that this workload
generates through writeback.

i.e. while throughput increases, that's not the numbers that matters
here - it's the change in write IO behaviour that needs to be
categorised and measured by the different patches...

(I'm on holidays, so I'm not going to get to this any time soon)

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Please remove commit 6609b638353c99c5736e05abd17197f1cb776e0e as it makes me feel miserable

[Diego Viola]

Hello,

Can someone please remove this commit from the repo:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/README?id=6609b638353c99c5736e05abd17197f1cb776e0e

I made a huge grammar mistake in my commit message that I can't
forget, it makes me feel terrible and I can't stop thinking about it.

Please rewrite the history for the README or whatever, but just make
this commit go away.

It should have been spelled as:

"README: GTK+ is an acronym"

or

"README: GTK+ is an initialism"

But saying "a acronym" is just wrong.

Thanks and sorry about this mistake, English isn't my native language. :-(

Diego
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 0/3] variuos perf fixes

[Vince Weaver]

On Thu, 10 Sep 2015, Peter Zijlstra wrote:

> Vince reported some fail here:
> 
>   
> lkml.kernel.org/r/alpine.deb.2.20.1509021227380.32...@vincent-weaver-1.umelst.maine.edu
> 
> These patches are the result of me trying to fix it.
> 
> Compile tested only, I'll try them after a sleep..

Sorry for the delay testing, your e-mails continue being sent to SPAM by 
gmail for some reason.

I patched up a 4.3-rc1 system with the patches, and pretty much my 
*entire* perf_event test suite causes kernel oopses.

This is on an AMD a10 system.

[ 1564.442224] BUG: unable to handle kernel NULL pointer dereference at 
01e8
[ 1564.450151] IP: [] SYSC_perf_event_open+0x60f/0x985
[ 1564.456655] PGD 8d691067 PUD 8d705067 PMD 0 
[ 1564.461013] Oops:  [#1] SMP 
[ 1564.464307] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs 
lockd grace fscache sunrpc nls_utf8 nls_cp437 vfat fat snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_codec_hdmi kvm_amd kvm ghash_clmulni_intel 
snd_hda_intel ppdev sha256_generic hmac drbg ansi_cprng snd_hda_codec 
snd_hda_core tpm_infineon evdev snd_hwdep hp_wmi sparse_keymap aesni_intel 
aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper snd_pcm radeon ttm 
drm_kms_helper drm psmouse serio_raw pcspkr i2c_algo_bit efivars pl2303 
fb_sys_fops k10temp snd_timer acpi_cpufreq usbserial parport_pc shpchp 
i2c_piix4 syscopyarea parport wmi sysfillrect i2c_core snd button processor 
sysimgblt soundcore tpm_tis tpm sg sr_mod cdrom sd_mod ohci_pci xhci_pci 
ohci_hcd ehci_pci ahci xhci_hcd ehci_hcd tg3 libahci ptp crc32c_intel pps_core
[ 1564.537217]  libphy libata usbcore scsi_mod usb_common
[ 1564.541187] CPU: 3 PID: 2077 Comm: branches Tainted: GW   
4.3.0-rc1+ #8
[ 1564.548884] Hardware name: Hewlett-Packard HP Compaq Pro 6305 SFF/1850, BIOS 
K06 v02.57 08/16/2013
[ 1564.557889] task: 88009c7c2140 ti: 88008d724000 task.ti: 
88008d724000
[ 1564.565413] RIP: 0010:[]  [] 
SYSC_perf_event_open+0x60f/0x985
[ 1564.574360] RSP: 0018:88008d727e78  EFLAGS: 00010287
[ 1564.579701] RAX: 880224155400 RBX: 8802240e5800 RCX: 0020
[ 1564.586870] RDX: 88022de31cc0 RSI: 88022654e060 RDI: 88009d1e3918
[ 1564.594037] RBP:  R08: 81816d80 R09: 
[ 1564.601204] R10:  R11: 0002 R12: 88022620bc00
[ 1564.608373] R13:  R14: 2620bc00 R15: 88009c7c2140
[ 1564.615542] FS:  7f5177613700() GS:88022ed8() 
knlGS:
[ 1564.623678] CS:  0010 DS:  ES:  CR0: 80050033
[ 1564.629455] CR2: 01e8 CR3: 8d556000 CR4: 000406e0
[ 1564.636623] Stack:
[ 1564.638647]  88020002 880224155400  
81816d80
[ 1564.646150]  0103   
0070
[ 1564.653648]  0004   

[ 1564.661157] Call Trace:
[ 1564.663629]  [] ? entry_SYSCALL_64_fastpath+0x16/0x6e
[ 1564.670280] Code: 48 89 44 24 08 76 24 44 8b 74 24 08 e9 df 00 00 00 48 8b 
74 24 10 48 89 df e8 60 bf ff ff 85 c0 41 89 c6 0f 85 c7 00 00 00 eb b6 <48> 8b 
85 e8 01 00 00 45 85 ed 4d 8d 7c 24 10 48 89 04 24 74 1f 
[ 1564.690602] RIP  [] SYSC_perf_event_open+0x60f/0x985
[ 1564.697183]  RSP 
[ 1564.700695] CR2: 01e8
[ 1564.710184] ---[ end trace 5b268a35cc2e53a3 ]---

addr2line -e ./vmlinux 0x810daf91
/home/vince/research/linux-kernel/linux.git/kernel/events/core.c:8323

if (IS_ERR(event_file)) {
err = PTR_ERR(event_file);
goto err_context;
}

gctx = group_leader->ctx;
^ = line 8323
if (move_group)
mutex_lock_double(>mutex, >mutex);
else
mutex_lock(>mutex);



Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] ARM: dts: rockchip: Add dtb for the Radxa Rock 2 Square board

[Javier Martinez Canillas]

Hello Sjoerd,

On Sat, Sep 12, 2015 at 12:36 AM, Sjoerd Simons
 wrote:

[snip]

> +
> +   regulators {
> +   vcc_ddr: REG1 {
> +   regulator-name = "VCC_DDR";
> +   regulator-min-microvolt = <120>;
> +   regulator-max-microvolt = <120>;
> +   regulator-always-on;
> +   };
> +
> +   vcc_io: REG2 {
> +   regulator-name = "VCC_IO";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-always-on;
> +   };
> +
> +   vdd_log: REG3 {
> +   regulator-name = "VDD_LOG";
> +   regulator-min-microvolt = <100>;
> +   regulator-max-microvolt = <100>;
> +   regulator-always-on;
> +   };
> +
> +   vcc_20: REG4 {
> +   regulator-name = "VCC_20";
> +   regulator-min-microvolt = <200>;
> +   regulator-max-microvolt = <200>;
> +   regulator-always-on;
> +   };
> +
> +   vccio_sd: REG5 {
> +   regulator-name = "VCCIO_SD";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-always-on;
> +   };
> +
> +   vdd10_lcd: REG6 {
> +   regulator-name = "VDD10_LCD";
> +   regulator-min-microvolt = <100>;
> +   regulator-max-microvolt = <100>;
> +   regulator-always-on;
> +   };
> +
> +   vcca_codec: REG7 {
> +   regulator-name = "VCCA_CODEC";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-always-on;
> +   };
> +
> +   vcca_tp: REG8 {
> +   regulator-name = "VCCA_TP";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-always-on;
> +   };
> +
> +   vccio_pmu: REG9 {
> +   regulator-name = "VCCIO_PMU";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-always-on;
> +   };
> +
> +   vdd_10: REG10 {
> +   regulator-name = "VDD_10";
> +   regulator-min-microvolt = <100>;
> +   regulator-max-microvolt = <100>;
> +   regulator-always-on;
> +   };
> +
> +   vcc_18: REG11 {
> +   regulator-name = "VCC_18";
> +   regulator-min-microvolt = <180>;
> +   regulator-max-microvolt = <180>;
> +   regulator-always-on;
> +   };
> +
> +   vcc18_lcd: REG12 {
> +   regulator-name = "VCC18_LCD";
> +   regulator-min-microvolt = <180>;
> +   regulator-max-microvolt = <180>;
> +   regulator-always-on;
> +   };

Should all these regulators really need to be always-on?

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()

[Dave Chinner]

On Sun, Sep 13, 2015 at 09:12:44AM -0400, Chris Mason wrote:
> On Sat, Sep 12, 2015 at 07:46:32PM -0400, Chris Mason wrote:
> > I don't think the XFS numbers can be trusted too much since it was
> > basically bottlenecked behind that single pegged CPU.  It was bouncing
> > around and I couldn't quite track it down to a process name (or perf
> > profile).
> 
> I'll do more runs Monday, but I was able to grab a perf profile of the
> pegged XFS CPU.  It was just the writeback worker thread, and it
> hit btrfs differently because we defer more of this stuff to endio
> workers, effectively spreading it out over more CPUs.
> 
> With 4 mount points intead of 2, XFS goes from 140K files/sec to 250K.
> Here's one of the profiles, but it bounced around a lot so I wouldn't
> use this to actually tune anything:

mkfs.xfs -d agcount=64 

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] atomics,cmpxchg: Privatize the inclusion of asm/cmpxchg.h

[Davidlohr Bueso]

On Wed, 09 Sep 2015, Boqun Feng wrote:


After commit:

atomics: add acquire/release/relaxed variants of some atomic operations

Architectures may only provide {cmp,}xchg_relaxed definitions in
asm/cmpxchg.h. Other variants, such as {cmp,}xchg, may be built in
linux/atomic.h, which means simply including asm/cmpxchg.h may not get
the definitions of all the{cmp,}xchg variants. Therefore, we should
privatize the inclusions of asm/cmpxchg.h to keep it only included in
arch/* and replace the inclusions outside with linux/atomic.h

Acked-by: Will Deacon 
Signed-off-by: Boqun Feng 


fwiw,

Acked-by: Davidlohr Bueso 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [media] lnbh25: Fix lnbh25_attach() function return type

[Javier Martinez Canillas]

If CONFIG_DVB_LNBH25 is disabled, a stub static inline function is
defined that just prints a warning about the driver being disabled
but the function return type was wrong which caused a build error.

Fixes: e025273b86fb ("[media] lnbh25: LNBH25 SEC controller driver")
Reported-by: Fengguang Wu 
Signed-off-by: Javier Martinez Canillas 

---
The offending commit landed in v4.3-rc1 so this patch is -rc material.

 drivers/media/dvb-frontends/lnbh25.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/lnbh25.h 
b/drivers/media/dvb-frontends/lnbh25.h
index 69f30e21f6b3..1f329ef05acc 100644
--- a/drivers/media/dvb-frontends/lnbh25.h
+++ b/drivers/media/dvb-frontends/lnbh25.h
@@ -43,7 +43,7 @@ struct dvb_frontend *lnbh25_attach(
struct lnbh25_config *cfg,
struct i2c_adapter *i2c);
 #else
-static inline dvb_frontend *lnbh25_attach(
+static inline struct dvb_frontend *lnbh25_attach(
struct dvb_frontend *fe,
struct lnbh25_config *cfg,
struct i2c_adapter *i2c)
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] [media] horus3a: Fix horus3a_attach() function parameters

[Javier Martinez Canillas]

If CONFIG_DVB_HORUS3A is disabled a stub static inline function is
defined that just prints a warning about the driver being disabled
but the function parameters were wrong which caused a build error.

Fixes: a5d32b358254f ("[media] horus3a: Sony Horus3A DVB-S/S2 tuner driver")
Reported-by: Fengguang Wu 
Signed-off-by: Javier Martinez Canillas 

---
The offending commit landed in v4.3-rc1 so this patch is -rc material.

Changes in v2:
- Added a Fixes tag which was forgotten on v1, sorry for the noise.

 drivers/media/dvb-frontends/horus3a.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/horus3a.h 
b/drivers/media/dvb-frontends/horus3a.h
index b055319d532e..c1e2d1834b78 100644
--- a/drivers/media/dvb-frontends/horus3a.h
+++ b/drivers/media/dvb-frontends/horus3a.h
@@ -46,8 +46,8 @@ extern struct dvb_frontend *horus3a_attach(struct 
dvb_frontend *fe,
const struct horus3a_config *config,
struct i2c_adapter *i2c);
 #else
-static inline struct dvb_frontend *horus3a_attach(
-   const struct cxd2820r_config *config,
+static inline struct dvb_frontend *horus3a_attach(struct dvb_frontend *fe,
+   const struct horus3a_config *config,
struct i2c_adapter *i2c)
 {
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [media] horus3a: Fix horus3a_attach() function parameters

[Javier Martinez Canillas]

If CONFIG_DVB_HORUS3A is disabled a stub static inline function is
defined that just prints a warning about the driver being disabled
but the function parameters were wrong which caused a build error.

Reported-by: Fengguang Wu 
Signed-off-by: Javier Martinez Canillas 

---

 drivers/media/dvb-frontends/horus3a.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/horus3a.h 
b/drivers/media/dvb-frontends/horus3a.h
index b055319d532e..c1e2d1834b78 100644
--- a/drivers/media/dvb-frontends/horus3a.h
+++ b/drivers/media/dvb-frontends/horus3a.h
@@ -46,8 +46,8 @@ extern struct dvb_frontend *horus3a_attach(struct 
dvb_frontend *fe,
const struct horus3a_config *config,
struct i2c_adapter *i2c);
 #else
-static inline struct dvb_frontend *horus3a_attach(
-   const struct cxd2820r_config *config,
+static inline struct dvb_frontend *horus3a_attach(struct dvb_frontend *fe,
+   const struct horus3a_config *config,
struct i2c_adapter *i2c)
 {
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

[Ilia Mirkin]

On Sun, Sep 13, 2015 at 6:01 PM, Ondrej Zary  wrote:
> On Sunday 13 September 2015 21:12:25 Ilia Mirkin wrote:
>> On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary  
>> wrote:
>> > Hello,
>> > I have a PC Chips A31G board with AGPro slot and found that nouveau does
>> > not work properly with it. Console works but reverts to software mode,
>> > X11 hangs with mouse cursor only.
>> >
>> > The slot is physically AGP 1.5V but is wired to PCI bus as the chipset
>> > (SiS 761) does not support AGP cards. To further complicate things, the
>> > chipset has AGP capability - but only for the integrated video. You can
>> > see that in the lspci output below - the AGP card is on bus 0 and SiS
>> > card on bus 1 (AGP bus behind the AGP bridge). The SiS card is not used
>> > (can be disabled in BIOS but it does not improve things - as the AGP
>> > capability of the host bridge remains active).
>>
>> I believe we can handle it with a blacklist. If the chipset just
>> doesn't support AGP at all, we should just set agpmode=0 irrespective
>> of the card plugged in, right?
>>
>> Shouldn't the agpgart know about this and not even allow any setting
>> at all? This is where we get the idea to set 8x AGP from. See
>> drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c for details.
>
> The chipset does not support AGP slot but supports AGP for the integrated
> video. So it shouldn't be completely disabled.
>
>> The alternative is to add to nvkm_device_agp_quirks, and just add
>> something that matches just the host bridge vendor/device, ignoring
>> the chip.
>
> Something like this?

Yes, precisely what I had in mind. I don't know if this is the "right"
solution, but it'll definitely work. Ideally we'd somehow find out
from the agpgart that we shouldn't be trying to use AGP, since adding
this quirk to every agp-supporting driver seems like a pain. OTOH this
is long-dead hardware, so a quick hack like this is fine by me. radeon
has a much more extensive list IIRC, may want to add it in there as
well for good measure if it's not already there.

  -ilia

>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
> index 814cb51..385a90f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
> @@ -35,6 +35,8 @@ static const struct nvkm_device_agp_quirk
>  nvkm_device_agp_quirks[] = {
> /* VIA Apollo PRO133x / GeForce FX 5600 Ultra - fdo#20341 */
> { PCI_VENDOR_ID_VIA, 0x0691, PCI_VENDOR_ID_NVIDIA, 0x0311, 2 },
> +   /* SiS 761 does not support AGP cards, use PCI mode */
> +   { PCI_VENDOR_ID_SI, 0x0761, PCI_ANY_ID, PCI_ANY_ID, 0 },
> {},
>  };
>
> @@ -137,8 +139,10 @@ nvkm_agp_ctor(struct nvkm_pci *pci)
> while (quirk->hostbridge_vendor) {
> if (info.device->vendor == quirk->hostbridge_vendor &&
> info.device->device == quirk->hostbridge_device &&
> -   pci->pdev->vendor == quirk->chip_vendor &&
> -   pci->pdev->device == quirk->chip_device) {
> +   (quirk->chip_vendor == (u16)PCI_ANY_ID ||
> +   pci->pdev->vendor == quirk->chip_vendor) &&
> +   (quirk->chip_device == (u16)PCI_ANY_ID ||
> +   pci->pdev->device == quirk->chip_device)) {
> nvkm_info(subdev, "forcing default agp mode to %dX, "
>   "use NvAGP= to override\n",
>   quirk->mode);
> --
> Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

[Ondrej Zary]

On Sunday 13 September 2015 21:12:25 Ilia Mirkin wrote:
> On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary  
> wrote:
> > Hello,
> > I have a PC Chips A31G board with AGPro slot and found that nouveau does
> > not work properly with it. Console works but reverts to software mode,
> > X11 hangs with mouse cursor only.
> >
> > The slot is physically AGP 1.5V but is wired to PCI bus as the chipset
> > (SiS 761) does not support AGP cards. To further complicate things, the
> > chipset has AGP capability - but only for the integrated video. You can
> > see that in the lspci output below - the AGP card is on bus 0 and SiS
> > card on bus 1 (AGP bus behind the AGP bridge). The SiS card is not used
> > (can be disabled in BIOS but it does not improve things - as the AGP
> > capability of the host bridge remains active).
>
> I believe we can handle it with a blacklist. If the chipset just
> doesn't support AGP at all, we should just set agpmode=0 irrespective
> of the card plugged in, right?
>
> Shouldn't the agpgart know about this and not even allow any setting
> at all? This is where we get the idea to set 8x AGP from. See
> drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c for details.

The chipset does not support AGP slot but supports AGP for the integrated
video. So it shouldn't be completely disabled.

> The alternative is to add to nvkm_device_agp_quirks, and just add
> something that matches just the host bridge vendor/device, ignoring
> the chip.

Something like this?

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
index 814cb51..385a90f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
@@ -35,6 +35,8 @@ static const struct nvkm_device_agp_quirk
 nvkm_device_agp_quirks[] = {
/* VIA Apollo PRO133x / GeForce FX 5600 Ultra - fdo#20341 */
{ PCI_VENDOR_ID_VIA, 0x0691, PCI_VENDOR_ID_NVIDIA, 0x0311, 2 },
+   /* SiS 761 does not support AGP cards, use PCI mode */
+   { PCI_VENDOR_ID_SI, 0x0761, PCI_ANY_ID, PCI_ANY_ID, 0 },
{},
 };
 
@@ -137,8 +139,10 @@ nvkm_agp_ctor(struct nvkm_pci *pci)
while (quirk->hostbridge_vendor) {
if (info.device->vendor == quirk->hostbridge_vendor &&
info.device->device == quirk->hostbridge_device &&
-   pci->pdev->vendor == quirk->chip_vendor &&
-   pci->pdev->device == quirk->chip_device) {
+   (quirk->chip_vendor == (u16)PCI_ANY_ID ||
+   pci->pdev->vendor == quirk->chip_vendor) &&
+   (quirk->chip_device == (u16)PCI_ANY_ID ||
+   pci->pdev->device == quirk->chip_device)) {
nvkm_info(subdev, "forcing default agp mode to %dX, "
  "use NvAGP= to override\n",
  quirk->mode);
-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] scripts/kernel-doc: Replacing highlights hash by an array

[Lukas Wunner]

Hi,

On Sun, Sep 13, 2015 at 02:36:47PM -0600, Jonathan Corbet wrote:
> On Mon,  7 Sep 2015 17:01:59 -0300
> Danilo Cesar Lemes de Paula  wrote:
> > The "highlight" code is very sensible to the order of the hash keys,
> > but the order of the keys cannot be predicted. It generates
> > faulty DocBook entries like:
> > - @device_for_each_child
> > 
> > Sorting the result is not enough some times (as it's deterministic but
> > we can't control it).
> > We should use an array for that job, so we can guarantee that the order
> > of the regex execution on dohighlight is correct.
> OK, I've spent a bunch of time with this, comparing the results before
> and after.  The output you mention is clearly wrong, but there might be
> room to differ over what the root cause is.
> 
> That output is caused by @device_for_each_child() in the comments.  This
> happens for a few other functions as well, and I think it's wrong.  @ is
> used to indicate parameters (or structure fields); I'm not sure why
> people are using it for functions that are *not* one of the above.
> Formatting the function names as a parameter doesn't seem right either.

Shouldn't kernel-doc print a warning for syntactic mistakes like this
rather than silently accomodating to it in whatever way?

As to the usage of markdown in general, there's documentation coming up
for vga_switcheroo which makes use of that so I'd love to see it merged:
https://github.com/l1k/linux/commit/d1476d748b5f1adf5bffe8e0a8bafad1e879d22f
https://github.com/l1k/linux/commit/11c55ae65788162970d8fa23cd1fd2518af55d34

The large set of dependencies pulled in on Fedora is likely to be blamed
on the RedHat packaging being notoriously coarse-grained. By comparison,
Debian is extremely fine-grained, kind of the opposite extreme, and
therefore has comparatively few prerequisites:
https://packages.debian.org/jessie/pandoc

I do agree however that alternative tools with fewer dependencies should
be supported and it would be great if the markdown patches were amended
to that end.

Best regards,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] hwmon: (nct7802) hwmon: (nct7802) Add device tree support

[Constantine Shulyupin]

Introduced properties sensorX-type with string values
"disabled", "thermal diode", "thermistor" and "voltage".

Signed-off-by: Constantine Shulyupin 
---
Changed in v2:
- removed tempX_type
- introduced nuvoton,sensorX-type with string values

Changed in v1:
- Introduced tempX_type with numerical values
---
 drivers/hwmon/nct7802.c | 43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/nct7802.c b/drivers/hwmon/nct7802.c
index 3ce33d2..edd9063 100644
--- a/drivers/hwmon/nct7802.c
+++ b/drivers/hwmon/nct7802.c
@@ -1077,9 +1077,11 @@ static const struct regmap_config nct7802_regmap_config 
= {
.volatile_reg = nct7802_regmap_is_volatile,
 };
 
-static int nct7802_init_chip(struct nct7802_data *data)
+static int nct7802_init_chip(struct device_node *node,
+struct nct7802_data *data)
 {
int err;
+   int i;
 
/* Enable ADC */
err = regmap_update_bits(data->regmap, REG_START, 0x01, 0x01);
@@ -1092,7 +1094,34 @@ static int nct7802_init_chip(struct nct7802_data *data)
return err;
 
/* Enable Vcore and VCC voltage monitoring */
-   return regmap_update_bits(data->regmap, REG_VMON_ENABLE, 0x03, 0x03);
+   err =  regmap_update_bits(data->regmap, REG_VMON_ENABLE, 0x03, 0x03);
+   if (err)
+   return err;
+
+   for (i = 0; i < 3; i++) {
+   char propname[30];
+   const char *val;
+   int senor_type;
+
+   snprintf(propname, sizeof(propname), "nuvoton,sensor%d-type",
+i + 1);
+   err = of_property_read_string(node, propname, );
+   if (err < 0)
+   break;
+   if (!strcmp(val, "disabled"))
+   senor_type = 0;
+   else if (!strcmp(val, "thermal diode"))
+   senor_type = 1;
+   else if (!strcmp(val, "thermistor"))
+   senor_type = 2;
+   else if (!strcmp(val, "voltage"))
+   senor_type = 3;
+   else
+   return -EINVAL;
+   err = regmap_update_bits(data->regmap, REG_MODE,
+3 << 2 * i, senor_type << 2 * i);
+   }
+   return 0;
 }
 
 static int nct7802_probe(struct i2c_client *client,
@@ -1113,7 +1142,7 @@ static int nct7802_probe(struct i2c_client *client,
 
mutex_init(>access_lock);
 
-   ret = nct7802_init_chip(data);
+   ret = nct7802_init_chip(client->dev.of_node, data);
if (ret < 0)
return ret;
 
@@ -1133,10 +1162,18 @@ static const struct i2c_device_id nct7802_idtable[] = {
 };
 MODULE_DEVICE_TABLE(i2c, nct7802_idtable);
 
+#ifdef CONFIG_OF
+static const struct of_device_id nct7802_dt_match[] = {
+   { .compatible = "nuvoton,nct7802" },
+   { },
+};
+#endif
+
 static struct i2c_driver nct7802_driver = {
.class = I2C_CLASS_HWMON,
.driver = {
.name = DRVNAME,
+   .of_match_table = of_match_ptr(nct7802_dt_match),
},
.detect = nct7802_detect,
.probe = nct7802_probe,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements

[Daniel Vetter]

On Sun, Sep 13, 2015 at 9:13 PM, Jonathan Corbet  wrote:
> On Sun, 13 Sep 2015 12:36:07 +0200
> Daniel Vetter  wrote:
>
>> Personally I don't care which kind of text markup we pick and wich
>> converter, as long as the project looks reasonable far away from
>> immeninent death (way too many one-person projects on github in this
>> area).
>>
>> But if we have this discussion I'd like to decouple it from the other
>> kerneldoc improvemnts in this series (patches 1, 5 and 6). If we cant
>> agree on the text markup then drm docs will simply look a bit funny for
>> everyone else. But if the inline struct stuff won't happen 0-day will
>> scream around (and there's already patches which use the new layout).
>
> Those patches are:
>
> 1)  scripts/kernel-doc: Replacing highlights hash by an array
> 5)  scripts/kernel-doc: Improve Markdown results
> 6)  scripts/kernel-doc: Processing -nofunc for functions only
>
> #1 is fine, I'll merge that today.  #6 is already merged.  #5 is a markdown
> patch, though, and doesn't make sense without the others?  Are you thinking
> about #3 (drm/doc: Convert to markdown)?  That one would almost work (it
> depends on #2 currently) and it nicely shows *why* I'd like to get away from
> XML...

Sorry I mixed things up, #5 is ok to leave out. I thought about
"scripts/kernel-doc Allow struct arguments documentation in struct
body" but you already merged that one for 4.2. Which I missed, but
which is great since that's the one that would cause the big
conflicts.

>> > 2 We're constructing an increasingly complicated document-processing
>> >   mechanism with a lot of independently moving parts.  What if we
>> >   converted the whole document to markdown and dispensed with the XML
>> >   part altogether?  Making the source files simpler and dispensing with
>> >   the xmlto requirement would be a big win, IMO.
>>
>> Who's going to convert the almost 30kloc of xml template (which often have
>> large amounts of texts) and the over 60k kerneldoc comments that we have
>> already?
>
> I thought you'd do that :)
>
> Seriously, though, a change would be a big job.  There's a reason I've said
> several times that it would make no sense to delay the work at hand in the
> hopes of somebody doing this whole job instead.  But we can certainly
> ponder what might be better.
>
> Getting rid of the XML stuff may well simplify the whole process and make
> the documentation much more accessible for those who would change it; that
> could be a goal worth going for.  Oh, and anything requiring changes to the
> kerneldoc comments is going nowhere, that was never something I'd
> contemplated.  Those comments are fine.

Well my goal is to be able to have all the programmer docs in the
code, including any high-level overview sections to tie everything
together (hence hyperlinks and better formatting). But then you still
need some skeleton to make a coherent whole out of all the parts, and
I think the docbook xml templates we have serve rather fine for that
role. Writing text in xml is indeed horrid, but if we can create
in-line DOC: sections with decent formatting there's really no need
for that. From that angle this work here already has the goal to get
rid of the xml - I plane to move all the existing text in the drm.tmpl
xml into inline DOC: kerneldoc commets.

And at least gtkdoc (which we use extensively for the userpace
test/tools repo) relies on some xml thing to tie different topics
together too. So that seems pretty standard.

> But any such change needs a lot of thought and a reasonable proof of
> concept.  Meanwhile we have work that can make the docs better now, and I
> want to merge it.  But we should choose the tools we use carefully, and I
> anticipate a lot of opposition to one that has to drag in 70 Haskell
> packages with it.

Well personally I don't care about the exact tooling, as long as:
- it's a reasonable alive project
- packages available on distros (works for me on both debian and fedora)
- we can muck around with how things are integrated into overall docs
(which is the case since pandoc is only used as a paragraph formatter
here).

The last one is something we stumbled over for the userspace side
where we wanted to have better tooling for documenting testcases.
Upstream gtkdoc is receptive, but getting anything in takes forever
and then there's the 6 month release schedule too. And there's also
the problem that we can't change the kerneldoc grammar (e.g. gtkdoc
has the code comment parser integrated and ofc it has slightly
different rules to mark up references to structs/enums).

I'm also trying to build up a doc team here with a full-time tech
writer for drm/i915 topics. So I'm very much interested in keeping
this all alive. But I don't have the time to mass-convert everything
else, and I'm also not sure it's a good idea: In my experience all the
doc toolchain suck somewhat, and it's better to be consistent within a
project instead of proliferating different solutions. It's hard 

Re: [BUG] Kernel error when first driver unbind with empty MMC slot

[Petr Cvek]

Dne 13.9.2015 v 11:56 Robert Jarzmik napsal(a):
> Petr Cvek  writes:
> 
>> During testing of these patches
>>
>>  [PATCH] mmc: pxamci: fix card detect threaded interrupt
>>  [PATCH 1/3] dmaengine: virt-dma: don't always free descriptor upon 
>> completion
>>
>> I have found unrelated error.
>>
>> How to reproduce:
>>
>> 1) Remove any SD card
>> 2) No CPLD initial power for card (in magician.c, probably irrelevant)
>> 3) Boot into an initrd filesystem
>> 4) Run command echo -n "pxa2xx-mci.0" > 
>> /sys/class/mmc_host/mmc0/device/driver/unbind
>> 5) Error message will be printed:
>>
>> [ 97.877519] irq 39: nobody cared (try booting with the "irqpoll" option)
> 
> To go forward, I need to either :
>  - see the debug messages activated, especially the one pxamci_irq()
>  - or apply this patch [1] to see if it fixes the issue :
> 
> Cheers.
> 
> --
> Robert
> 
> [1] Patch, totally untested/not compiled
> ---8<---
> diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
> index 67c9d1443597..3e0a7dd8da84 100644
> --- a/drivers/mmc/host/pxamci.c
> +++ b/drivers/mmc/host/pxamci.c
> @@ -890,9 +890,7 @@ static int pxamci_remove(struct platform_device *pdev)
> host->pdata->exit(>dev, mmc);
>  
> pxamci_stop_clock(host);
> -   writel(TXFIFO_WR_REQ|RXFIFO_RD_REQ|CLK_IS_OFF|STOP_CMD|
> -  END_CMD_RES|PRG_DONE|DATA_TRAN_DONE,
> -  host->base + MMC_I_MASK);
> +   pxamci_disable_irq(host,  MMC_I_MASK_ALL);
>  
> free_irq(host->irq, host);
> dmaengine_terminate_all(host->dma_chan_rx);
> 

Yes, the patch fixes it. Log on unfixed version with debugging information 
enabled consists of many of a line:

[  125.01] PXAMCI: irq 0200 stat 2042

Petr Cvek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/