from:"Rafael J. Wysocki"

Re: [PATCH] sound, isapnp: allow building more drivers with COMPILE_TEST

2018-04-24 Thread Rafael J. Wysocki


On 4/20/2018 2:58 PM, Mauro Carvalho Chehab wrote:

Drivers that depend on ISAPNP currently can't be built with
COMPILE_TEST. However, looking at isapnp.h, there are already
stubs there to allow drivers to include it even when isa
PNP is not supported.

So, remove such dependencies when COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
---
  drivers/pnp/isapnp/Kconfig | 2 +-
  sound/isa/Kconfig  | 6 +++---
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pnp/isapnp/Kconfig b/drivers/pnp/isapnp/Kconfig
index f1ef36673ad4..a1af146d2d90 100644
--- a/drivers/pnp/isapnp/Kconfig
+++ b/drivers/pnp/isapnp/Kconfig
@@ -3,7 +3,7 @@
  #
  config ISAPNP
bool "ISA Plug and Play support"
-   depends on ISA
+   depends on ISA || COMPILE_TEST
help
  Say Y here if you would like support for ISA Plug and Play devices.
  Some information is in .
diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
index d2a6cdd0395c..43b35a873d78 100644
--- a/sound/isa/Kconfig
+++ b/sound/isa/Kconfig
@@ -39,7 +39,7 @@ config SND_ADLIB
  
  config SND_AD1816A

tristate "Analog Devices SoundPort AD1816A"
-   depends on PNP && ISA
+   depends on PNP
select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -67,7 +67,7 @@ config SND_AD1848
  
  config SND_ALS100

tristate "Diamond Tech. DT-019x and Avance Logic ALSxxx"
-   depends on PNP && ISA
+   depends on PNP
select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -108,7 +108,7 @@ config SND_AZT2316
  
  config SND_AZT2320

tristate "Aztech Systems AZT2320"
-   depends on PNP && ISA
+   depends on PNP
select ISAPNP
    select SND_OPL3_LIB
select SND_MPU401_UART



Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Re: [trivial PATCH] treewide: Align function definition open/close braces

2017-12-18 Thread Rafael J. Wysocki

(xfs_sb_version_hascrc(>m_sb)) {
> @@ -2449,8 +2449,7 @@ xfs_agf_verify(
>be32_to_cpu(agf->agf_refcount_level) > XFS_BTREE_MAXLEVELS))
>   return false;
>  
> - return true;;
> -
> + return true;
>  }
>  
>  static void
> diff --git a/fs/xfs/xfs_export.c b/fs/xfs/xfs_export.c
> index fe1bfee35898..7d5c355d78b5 100644
> --- a/fs/xfs/xfs_export.c
> +++ b/fs/xfs/xfs_export.c
> @@ -122,7 +122,7 @@ xfs_nfs_get_inode(
>   struct super_block  *sb,
>   u64 ino,
>   u32 generation)
> - {
> +{
>   xfs_mount_t *mp = XFS_M(sb);
>   xfs_inode_t *ip;
>   int error;
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 227db99b0f19..d97e8f0f73ca 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -443,15 +443,15 @@ static int audit_set_failure(u32 state)
>   * Drop any references inside the auditd connection tracking struct and free
>   * the memory.
>   */
> - static void auditd_conn_free(struct rcu_head *rcu)
> - {
> +static void auditd_conn_free(struct rcu_head *rcu)
> +{
>   struct auditd_connection *ac;
>  
>   ac = container_of(rcu, struct auditd_connection, rcu);
>   put_pid(ac->pid);
>   put_net(ac->net);
>   kfree(ac);
> - }
> +}
>  
>  /**
>   * auditd_set - Set/Reset the auditd connection state
> diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
> index ad1d6164e946..50f44b7b2b32 100644
> --- a/kernel/trace/trace_printk.c
> +++ b/kernel/trace/trace_printk.c
> @@ -196,7 +196,7 @@ struct notifier_block module_trace_bprintk_format_nb = {
>  };
>  
>  int __trace_bprintk(unsigned long ip, const char *fmt, ...)
> - {
> +{
>   int ret;
>   va_list ap;
>  
> @@ -214,7 +214,7 @@ int __trace_bprintk(unsigned long ip, const char *fmt, 
> ...)
>  EXPORT_SYMBOL_GPL(__trace_bprintk);
>  
>  int __ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap)
> - {
> +{
>   if (unlikely(!fmt))
>   return 0;
>  
> diff --git a/lib/raid6/sse2.c b/lib/raid6/sse2.c
> index 1d2276b007ee..8191e1d0d2fb 100644
> --- a/lib/raid6/sse2.c
> +++ b/lib/raid6/sse2.c
> @@ -91,7 +91,7 @@ static void raid6_sse21_gen_syndrome(int disks, size_t 
> bytes, void **ptrs)
>  
>  static void raid6_sse21_xor_syndrome(int disks, int start, int stop,
>size_t bytes, void **ptrs)
> - {
> +{
>   u8 **dptr = (u8 **)ptrs;
>   u8 *p, *q;
>   int d, z, z0;
> @@ -200,9 +200,9 @@ static void raid6_sse22_gen_syndrome(int disks, size_t 
> bytes, void **ptrs)
>   kernel_fpu_end();
>  }
>  
> - static void raid6_sse22_xor_syndrome(int disks, int start, int stop,
> +static void raid6_sse22_xor_syndrome(int disks, int start, int stop,
>size_t bytes, void **ptrs)
> - {
> +{
>   u8 **dptr = (u8 **)ptrs;
>   u8 *p, *q;
>   int d, z, z0;
> @@ -265,7 +265,7 @@ static void raid6_sse22_gen_syndrome(int disks, size_t 
> bytes, void **ptrs)
>  
>   asm volatile("sfence" : : : "memory");
>   kernel_fpu_end();
> - }
> +}
>  
>  const struct raid6_calls raid6_sse2x2 = {
>   raid6_sse22_gen_syndrome,
> @@ -366,9 +366,9 @@ static void raid6_sse24_gen_syndrome(int disks, size_t 
> bytes, void **ptrs)
>   kernel_fpu_end();
>  }
>  
> - static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
> +static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
>size_t bytes, void **ptrs)
> - {
> +{
>   u8 **dptr = (u8 **)ptrs;
>   u8 *p, *q;
>   int d, z, z0;
> @@ -471,7 +471,7 @@ static void raid6_sse24_gen_syndrome(int disks, size_t 
> bytes, void **ptrs)
>   }
>   asm volatile("sfence" : : : "memory");
>   kernel_fpu_end();
> - }
> +}
>  
>  
>  const struct raid6_calls raid6_sse2x4 = {
> diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> index 0c11f434a374..ec619f51d336 100644
> --- a/sound/soc/fsl/fsl_dma.c
> +++ b/sound/soc/fsl/fsl_dma.c
> @@ -879,7 +879,7 @@ static const struct snd_pcm_ops fsl_dma_ops = {
>  };
>  
>  static int fsl_soc_dma_probe(struct platform_device *pdev)
> - {
> +{
>   struct dma_object *dma;
>   struct device_node *np = pdev->dev.of_node;
>   struct device_node *ssi_np;
> 
> --

Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

for the ACPI part.

Thanks!

Re: [PATCH 2/8] Documentation: fix admin-guide doc refs

2017-10-10 Thread Rafael J. Wysocki

On Tue, Oct 10, 2017 at 7:36 PM, Tom Saeger <tom.sae...@oracle.com> wrote:
> Make admin-guide document refs valid.
>
> Signed-off-by: Tom Saeger <tom.sae...@oracle.com>

Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

> ---
>  Documentation/ABI/stable/sysfs-devices | 2 +-
>  Documentation/ABI/testing/sysfs-devices-system-cpu | 6 --
>  Documentation/ABI/testing/sysfs-power  | 6 --
>  Documentation/admin-guide/README.rst   | 2 +-
>  Documentation/admin-guide/kernel-parameters.txt| 4 ++--
>  Documentation/admin-guide/reporting-bugs.rst   | 4 ++--
>  Documentation/laptops/laptop-mode.txt  | 6 +++---
>  Documentation/media/v4l-drivers/bttv.rst   | 2 +-
>  Documentation/power/interface.txt  | 3 ++-
>  9 files changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-devices 
> b/Documentation/ABI/stable/sysfs-devices
> index 35c457f8ce73..4404bd9b96c1 100644
> --- a/Documentation/ABI/stable/sysfs-devices
> +++ b/Documentation/ABI/stable/sysfs-devices
> @@ -1,5 +1,5 @@
>  # Note: This documents additional properties of any device beyond what
> -# is documented in Documentation/sysfs-rules.txt
> +# is documented in Documentation/admin-guide/sysfs-rules.rst
>
>  What:  /sys/devices/*/of_node
>  Date:  February 2015
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu 
> b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index f3d5817c4ef0..d6d862db3b5d 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -187,7 +187,8 @@ Description:Processor frequency boosting control
> This switch controls the boost setting for the whole system.
> Boosting allows the CPU and the firmware to run at a frequency
> beyound it's nominal limit.
> -   More details can be found in Documentation/cpu-freq/boost.txt
> +   More details can be found in
> +   Documentation/admin-guide/pm/cpufreq.rst
>
>
>  What:  /sys/devices/system/cpu/cpu#/crash_notes
> @@ -223,7 +224,8 @@ Description:Parameters for the Intel P-state 
> driver
> no_turbo: limits the driver to selecting P states below the 
> turbo
> frequency range.
>
> -   More details can be found in 
> Documentation/cpu-freq/intel-pstate.txt
> +   More details can be found in
> +   Documentation/admin-guide/pm/intel_pstate.rst
>
>  What:  
> /sys/devices/system/cpu/cpu*/cache/index*/
>  Date:  July 2014(documented, existed before August 2008)
> diff --git a/Documentation/ABI/testing/sysfs-power 
> b/Documentation/ABI/testing/sysfs-power
> index a1d1612f3651..1e0d1dac706b 100644
> --- a/Documentation/ABI/testing/sysfs-power
> +++ b/Documentation/ABI/testing/sysfs-power
> @@ -18,7 +18,8 @@ Description:
> Writing one of the above strings to this file causes the 
> system
> to transition into the corresponding state, if available.
>
> -   See Documentation/power/states.txt for more information.
> +   See Documentation/admin-guide/pm/sleep-states.rst for more
> +   information.
>
>  What:  /sys/power/mem_sleep
>  Date:  November 2016
> @@ -35,7 +36,8 @@ Description:
> represented by it to be used on subsequent attempts to suspend
> the system.
>
> -   See Documentation/power/states.txt for more information.
> +   See Documentation/admin-guide/pm/sleep-states.rst for more
> +   information.
>
>  What:  /sys/power/disk
>  Date:  September 2006
> diff --git a/Documentation/admin-guide/README.rst 
> b/Documentation/admin-guide/README.rst
> index b5343c5aa224..63066db39910 100644
> --- a/Documentation/admin-guide/README.rst
> +++ b/Documentation/admin-guide/README.rst
> @@ -350,7 +350,7 @@ If something goes wrong
> help debugging the problem.  The text above the dump is also
> important: it tells something about why the kernel dumped code (in
> the above example, it's due to a bad kernel pointer). More information
> -   on making sense of the dump is in 
> Documentation/admin-guide/oops-tracing.rst
> +   on making sense of the dump is in 
> Documentation/admin-guide/bug-hunting.rst
>
>   - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
> as is, otherwise you will have to use the ``ksymoops`` program to make
> diff --git a/Documentation/a

Re: [PATCH v10 00/24] Unified fwnode endpoint parser, async sub-device notifier support, N9 flash DTS

2017-10-02 Thread Rafael J. Wysocki

Hi,

On Mon, Sep 11, 2017 at 9:59 AM, Sakari Ailus
 wrote:
> Hi folks,
>
> We have a large influx of new, unmerged, drivers that are now parsing
> fwnode endpoints and each one of them is doing this a little bit
> differently. The needs are still exactly the same for the graph data
> structure is device independent. This is still a non-trivial task and the
> majority of the driver implementations are buggy, just buggy in different
> ways.
>
> Facilitate parsing endpoints by adding a convenience function for parsing
> the endpoints, and make the omap3isp and rcar-vin drivers use them as an
> example.
>
> To show where we're getting with this, I've added support for async
> sub-device notifier support that is notifiers that can be registered by
> sub-device drivers as well as V4L2 fwnode improvements to make use of them
> and the DTS changes for the Nokia N9. Some of these patches I've posted
> previously in this set here:
>
> 
>
> Since that, the complete callback of the master notifier registering the
> V4L2 device is only called once all sub-notifiers have been completed as
> well. This way the device node creation can be postponed until all devices
> have been successfully initialised.
>
> With this, the as3645a driver successfully registers a sub-device to the
> media device created by the omap3isp driver. The kernel also has the
> information it's related to the sensor driven by the smiapp driver but we
> don't have a way to expose that information yet.

I don't see core changes in this set, so I'm assuming it to be
targeted at the users of endpoints etc.

Thanks,
Rafael

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-17 Thread Rafael J. Wysocki

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches  wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning for that directory tree and pr_warn is
> not used in tools/.
>
> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.

Sorry about asking if that has been asked already.

Wouldn't it be slightly less intrusive to simply redefined
pr_warning() as a synonym for pr_warn()?

Thanks,
Rafael

Re: [PATCH] media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

2014-12-04 Thread Rafael J. Wysocki

On Thursday, December 04, 2014 04:08:40 PM Mauro Carvalho Chehab wrote:
 Em Wed, 03 Dec 2014 03:13:55 +0100
 Rafael J. Wysocki r...@rjwysocki.net escreveu:
 
  From: Rafael J. Wysocki rafael.j.wyso...@intel.com
  
  After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
  selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
  depending on CONFIG_PM_RUNTIME may now be changed to depend on
  CONFIG_PM.
  
  The alternative of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME may be
  replaced with CONFIG_PM too.
  
  Make these changes everywhere under drivers/media/.
  
  Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 
 Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
 
 Feel free to apply it via your tree.

Thanks!

 PS.: I won't doubt that you would find some extra checks for
 PM_RUNTIME on other places at media, as I remember I merged some
 things like that recently - I think they are there for 3.19, but
 it needs to be double-checked.

That's fine.  There is at least one case when I need to wait for
other trees to get merged due to files being moved around, so I'll
do a second round during the merge window anyway.

Kind regards,
Rafael

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

2014-12-02 Thread Rafael J. Wysocki

From: Rafael J. Wysocki rafael.j.wyso...@intel.com

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

The alternative of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME may be
replaced with CONFIG_PM too.

Make these changes everywhere under drivers/media/.

Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 drivers/media/platform/coda/coda-common.c   |4 ++--
 drivers/media/platform/exynos4-is/fimc-core.c   |6 +++---
 drivers/media/platform/exynos4-is/fimc-is-i2c.c |2 +-
 drivers/media/platform/exynos4-is/fimc-lite.c   |2 +-
 drivers/media/platform/exynos4-is/mipi-csis.c   |2 +-
 drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc.c|2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |   10 --
 8 files changed, 15 insertions(+), 17 deletions(-)

Index: linux-pm/drivers/media/platform/s5p-jpeg/jpeg-core.c
===
--- linux-pm.orig/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ linux-pm/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2632,7 +2632,7 @@ static int s5p_jpeg_remove(struct platfo
return 0;
 }
 
-#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_PM_SLEEP)
+#ifdef CONFIG_PM
 static int s5p_jpeg_runtime_suspend(struct device *dev)
 {
struct s5p_jpeg *jpeg = dev_get_drvdata(dev);
@@ -2682,7 +2682,7 @@ static int s5p_jpeg_runtime_resume(struc
 
return 0;
 }
-#endif /* CONFIG_PM_RUNTIME || CONFIG_PM_SLEEP */
+#endif /* CONFIG_PM */
 
 #ifdef CONFIG_PM_SLEEP
 static int s5p_jpeg_suspend(struct device *dev)
Index: linux-pm/drivers/media/platform/s5p-mfc/s5p_mfc.c
===
--- linux-pm.orig/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ linux-pm/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1302,7 +1302,7 @@ static int s5p_mfc_resume(struct device
 }
 #endif
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int s5p_mfc_runtime_suspend(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
Index: linux-pm/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
===
--- linux-pm.orig/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ linux-pm/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -13,9 +13,7 @@
 #include linux/clk.h
 #include linux/err.h
 #include linux/platform_device.h
-#ifdef CONFIG_PM_RUNTIME
 #include linux/pm_runtime.h
-#endif
 #include s5p_mfc_common.h
 #include s5p_mfc_debug.h
 #include s5p_mfc_pm.h
@@ -67,7 +65,7 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *
}
 
atomic_set(pm-power, 0);
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
pm-device = dev-plat_dev-dev;
pm_runtime_enable(pm-device);
 #endif
@@ -93,7 +91,7 @@ void s5p_mfc_final_pm(struct s5p_mfc_dev
}
clk_unprepare(pm-clock_gate);
clk_put(pm-clock_gate);
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
pm_runtime_disable(pm-device);
 #endif
 }
@@ -120,7 +118,7 @@ void s5p_mfc_clock_off(void)
 
 int s5p_mfc_power_on(void)
 {
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
return pm_runtime_get_sync(pm-device);
 #else
atomic_set(pm-power, 1);
@@ -130,7 +128,7 @@ int s5p_mfc_power_on(void)
 
 int s5p_mfc_power_off(void)
 {
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
return pm_runtime_put_sync(pm-device);
 #else
atomic_set(pm-power, 0);
Index: linux-pm/drivers/media/platform/exynos4-is/fimc-is-i2c.c
===
--- linux-pm.orig/drivers/media/platform/exynos4-is/fimc-is-i2c.c
+++ linux-pm/drivers/media/platform/exynos4-is/fimc-is-i2c.c
@@ -81,7 +81,7 @@ static int fimc_is_i2c_remove(struct pla
return 0;
 }
 
-#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_PM_SLEEP)
+#ifdef CONFIG_PM
 static int fimc_is_i2c_runtime_suspend(struct device *dev)
 {
struct fimc_is_i2c *isp_i2c = dev_get_drvdata(dev);
Index: linux-pm/drivers/media/platform/exynos4-is/fimc-lite.c
===
--- linux-pm.orig/drivers/media/platform/exynos4-is/fimc-lite.c
+++ linux-pm/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -1588,7 +1588,7 @@ err_clk_put:
return ret;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int fimc_lite_runtime_resume(struct device *dev)
 {
struct fimc_lite *fimc = dev_get_drvdata(dev);
Index: linux-pm/drivers/media/platform/exynos4-is/mipi-csis.c

Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN

2013-07-29 Thread Rafael J. Wysocki

 *addr);
  
 - unsigned char mac_addr[6];
 + unsigned char mac_addr[ETH_ALEN];
   unsigned no_ether_link:1;
   unsigned ether_link_active_low:1;
   unsigned needs_init:1;
 diff --git a/include/linux/smsc911x.h b/include/linux/smsc911x.h
 index 4dde70e..eec3efd 100644
 --- a/include/linux/smsc911x.h
 +++ b/include/linux/smsc911x.h
 @@ -22,6 +22,7 @@
  #define __LINUX_SMSC911X_H__
  
  #include linux/phy.h
 +#include linux/if_ether.h
  
  /* platform_device configuration data, should be assigned to
   * the platform_device's dev.platform_data */
 @@ -31,7 +32,7 @@ struct smsc911x_platform_config {
   unsigned int flags;
   unsigned int shift;
   phy_interface_t phy_interface;
 - unsigned char mac[6];
 + unsigned char mac[ETH_ALEN];
  };
  
  /* Constants for platform_device irq polarity configuration */
 diff --git a/include/linux/uwb/spec.h b/include/linux/uwb/spec.h
 index b52e44f..0df24bf 100644
 --- a/include/linux/uwb/spec.h
 +++ b/include/linux/uwb/spec.h
 @@ -32,6 +32,7 @@
  
  #include linux/types.h
  #include linux/bitmap.h
 +#include linux/if_ether.h
  
  #define i1480_FW 0x0303
  /* #define i1480_FW 0x0302 */
 @@ -130,7 +131,7 @@ enum { UWB_DRP_BACKOFF_WIN_MAX = 16 };
   * it is also used to define headers sent down and up the wire/radio).
   */
  struct uwb_mac_addr {
 - u8 data[6];
 + u8 data[ETH_ALEN];
  } __attribute__((packed));
  
  
 @@ -568,7 +569,7 @@ struct uwb_rc_evt_confirm {
  /* Device Address Management event. [WHCI] section 3.1.3.2. */
  struct uwb_rc_evt_dev_addr_mgmt {
   struct uwb_rceb rceb;
 - u8 baAddr[6];
 + u8 baAddr[ETH_ALEN];
   u8 bResultCode;
  } __attribute__((packed));
  
 diff --git a/include/media/tveeprom.h b/include/media/tveeprom.h
 index 4a1191a..f7119ee 100644
 --- a/include/media/tveeprom.h
 +++ b/include/media/tveeprom.h
 @@ -12,6 +12,8 @@ enum tveeprom_audio_processor {
   TVEEPROM_AUDPROC_OTHER,
  };
  
 +#include linux/if_ether.h
 +
  struct tveeprom {
   u32 has_radio;
   /* If has_ir == 0, then it is unknown what the IR capabilities are,
 @@ -40,7 +42,7 @@ struct tveeprom {
   u32 revision;
   u32 serial_number;
   char rev_str[5];
 - u8 MAC_address[6];
 + u8 MAC_address[ETH_ALEN];
  };
  
  void tveeprom_hauppauge_analog(struct i2c_client *c, struct tveeprom *tvee,
 diff --git a/include/net/irda/irlan_common.h b/include/net/irda/irlan_common.h
 index 0af8b8d..550c2d6 100644
 --- a/include/net/irda/irlan_common.h
 +++ b/include/net/irda/irlan_common.h
 @@ -32,6 +32,7 @@
  #include linux/types.h
  #include linux/skbuff.h
  #include linux/netdevice.h
 +#include linux/if_ether.h
  
  #include net/irda/irttp.h
  
 @@ -161,7 +162,7 @@ struct irlan_provider_cb {
   int access_type; /* Access type */
   __u16 send_arb_val;
  
 - __u8 mac_address[6]; /* Generated MAC address for peer device */
 + __u8 mac_address[ETH_ALEN]; /* Generated MAC address for peer device */
  };
  
  /*
 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN

2013-07-29 Thread Rafael J. Wysocki

On Monday, July 29, 2013 12:34:24 PM Joe Perches wrote:
 On Mon, 2013-07-29 at 13:59 +0200, Rafael J. Wysocki wrote:
  On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
   It's convenient to have ethernet mac addresses use
   ETH_ALEN to be able to grep for them a bit easier and
   also to ensure that the addresses are __aligned(2).
 []
   diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
 []
   @@ -44,6 +44,8 @@
 []
   +#include linux/if_ether.h
   +
 []
   @@ -605,7 +607,7 @@ struct acpi_ibft_nic {
 []
   - u8 mac_address[6];
   + u8 mac_address[ETH_ALEN];
 
  Please don't touch this file.
  
  It comes from a code base outside of the kernel and should be kept in sync 
  with
  the upstream.
 
 Which files in include/acpi have this characteristic?

Generally, all whose names start with ac except for acpi_bus.h,
acpi_drivers.h and acpi_numa.h.

 Perhaps an include/acpi/README is appropriate.

Yes, we can add one.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH, RFC 00/22] ARM randconfig bugs

2013-05-02 Thread Rafael J. Wysocki

On Thursday, May 02, 2013 05:16:04 PM Arnd Bergmann wrote:
 Hi subsystem maintainers,
 
 This is a set of patches to to fix build errors I hit while trying to
 build lots of randconfig kernels on linux-next.
 
 Most of them are simple missing dependencies in Kconfig, but some are
 more substantial. I would like to see at least the obvious patches
 get merged for 3.10. If you are happy with the patches, feel free
 to apply them directly, otherwise please provide feedback.
 
 No single patch out of these is very important though, most of them
 only concern corner cases and don't matter in practice.

For cpufreq and cpuidle:

Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com

 Arnd Bergmann (22):
   can: move CONFIG_HAVE_CAN_FLEXCAN out of CAN_DEV
   cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY
   cpuidle: calxeda: select ARM_CPU_SUSPEND
   staging/drm: imx: add missing dependencies
   drm: always provide debugfs function prototypes
   gpu/drm: host1x: add dependency on Tegra
   drm/tilcd: select BACKLIGHT_LCD_SUPPORT
   OMAPDSS: DPI needs DSI
   crypto: lz4: don't build on ARM
   mfd: ab8500: debugfs code depends on gpadc
   iwlegacy: il_pm_ops is only provided for PM_SLEEP
   thermal: cpu_cooling: fix stub function
   staging/logger: use kuid_t internally
   oprofile: always enable IRQ_WORK
   USB: EHCI: remove bogus #error
   USB: UHCI: clarify Kconfig dependencies
   USB: OHCI: clarify Kconfig dependencies
   Xen: SWIOTLB is only used on x86
   staging/solo6x10: depend on CONFIG_FONTS
   media: coda: select GENERIC_ALLOCATOR
   davinci: vpfe_capture needs i2c
   radio-si4713: depend on SND_SOC
 
  arch/Kconfig   |  1 +
  crypto/Kconfig |  2 ++
  drivers/cpufreq/Kconfig.arm|  1 +
  drivers/cpuidle/Kconfig|  1 +
  drivers/gpu/drm/tilcdc/Kconfig |  1 +
  drivers/gpu/host1x/drm/Kconfig |  1 +
  drivers/media/platform/Kconfig |  1 +
  drivers/media/platform/davinci/Kconfig |  3 ++
  drivers/media/radio/Kconfig|  1 +
  drivers/mfd/Kconfig|  2 +-
  drivers/net/can/Kconfig|  6 ++--
  drivers/net/wireless/iwlegacy/common.h |  2 +-
  drivers/staging/android/logger.c   |  4 +--
  drivers/staging/android/logger.h   |  2 +-
  drivers/staging/imx-drm/Kconfig|  4 +++
  drivers/staging/media/solo6x10/Kconfig |  1 +
  drivers/usb/host/Kconfig   | 65 
 +-
  drivers/usb/host/Makefile  |  4 +--
  drivers/usb/host/ehci-hcd.c| 17 -
  drivers/usb/host/ohci-hcd.c| 19 --
  drivers/usb/host/uhci-hcd.c|  4 +--
  drivers/video/console/Makefile |  2 ++
  drivers/video/omap2/dss/Kconfig|  1 +
  drivers/xen/Kconfig|  2 +-
  include/drm/drmP.h |  3 +-
  include/linux/cpu_cooling.h|  2 +-
  26 files changed, 91 insertions(+), 61 deletions(-)
 
 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] drm/exynos: prepare FIMD clocks

2013-04-22 Thread Rafael J. Wysocki

On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
 On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
  On 04/22/2013 12:03 PM, Inki Dae wrote:
Also looks good to me. But what if power domain was disabled without
pm
runtime? In this case, you must enable the power domain at machine
code or
bootloader somewhere. This way would not only need some hard codes
to turn
the power domain on but also not manage power management fully. This
is same as only the use of pm runtime interface(needing some hard
codes without pm runtime) so I don't prefer to add
clk_enable/disable to fimd probe(). I quite tend to force only the
use of pm runtime as possible. So please add the hard codes to
machine code or bootloader like you did for power domain if you
want to use drm fimd without pm runtime.
   
   That's not how the runtime PM, clock subsystems work:
   
   1) When CONFIG_PM_RUNTIME is disabled, all the used hardware must be
   kept
   powered on all the time.
   
   2) Common Clock Framework will always gate all clocks that have zero
   enable_count. Note that CCF support for Exynos is already merged for
   3.10 and it will be the only available clock support method for
   Exynos.
   
   AFAIK, drivers must work correctly in both cases, with
   CONFIG_PM_RUNTIME
   enabled and disabled.
   
   Then is the driver worked correctly if the power domain to this device was
   disabled at bootloader without CONFIG_PM_RUNTIME and with clk_enable()?  I
   think, in this case, the device wouldn't be worked correctly because the
   power of the device remains off. So you must enable the power domain
   somewhere. What is the difference between these two cases?
  
  How about making the driver dependant on PM_RUNTIME and making it always
  use pm_runtime_* API, regardless if the platform actually implements runtime
  PM or not ? Is there any issue in using the Runtime PM core always, rather
  than coding any workarounds in drivers when PM_RUNTIME is disabled ?
 
 I don't think this is a good idea. This would mean that any user that from 
 some reasons don't want to use PM_RUNTIME, would not be able to use the 
 driver 
 anymore.
 
 Rafael, Kevin, do you have any opinion on this?

I agree.

Drivers should work for CONFIG_PM_RUNTIME unset too and static inline stubs for
all runtime PM helpers are available in that case.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: outstanding ARM patches

2012-04-16 Thread Rafael J. Wysocki

On Friday, April 13, 2012, Guennadi Liakhovetski wrote:
 Hi
 
 Just confirming, that the 3 outstanding ARM patches, that I mentioned in 
 recent emails:
 
 http://article.gmane.org/gmane.linux.kernel.mmc/12748
 http://article.gmane.org/gmane.linux.ports.sh.devel/13535
 http://article.gmane.org/gmane.linux.ports.sh.devel/13975
 
 still apply to the current Linus' tree, though, the former 2 with a fuzz, 
 if needed, I can provide a version, that applies cleanly. Compile-tested.

Can you please repost them in one series on top of v3.2-rc3?

Rafael

 
 On Sun, 8 Apr 2012, Guennadi Liakhovetski wrote:
 
  On Wed, 14 Mar 2012, Guennadi Liakhovetski wrote:
  
   Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
   
   This patch we can push some time after the first one in this series gets 
   in, no breakage is caused.
  
  Patch 1/2 from this series is now in the mainline, so, also this patch can 
  be applied now. Not sure whether this qualifies as a fix (in the sense, 
  that the default maximum sizes of 2560x1920, used without this patch are 
  wrong for sh7372). Please, either push for 3.4 or queue for 3.5 
  accordingly.
 ...
arch/arm/mach-shmobile/board-ap4evb.c   |2 ++
arch/arm/mach-shmobile/board-mackerel.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
   
   diff --git a/arch/arm/mach-shmobile/board-ap4evb.c 
   b/arch/arm/mach-shmobile/board-ap4evb.c
   index aab0a34..f67aa03 100644
   --- a/arch/arm/mach-shmobile/board-ap4evb.c
   +++ b/arch/arm/mach-shmobile/board-ap4evb.c
   @@ -1009,6 +1009,8 @@ static struct sh_mobile_ceu_companion csi2 = {

static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
 .flags = SH_CEU_FLAG_USE_8BIT_BUS,
   + .max_width = 8188,
   + .max_height = 8188,
 .csi2 = csi2,
};

   diff --git a/arch/arm/mach-shmobile/board-mackerel.c 
   b/arch/arm/mach-shmobile/board-mackerel.c
   index 9b42fbd..f790772 100644
   --- a/arch/arm/mach-shmobile/board-mackerel.c
   +++ b/arch/arm/mach-shmobile/board-mackerel.c
   @@ -1270,6 +1270,8 @@ static void mackerel_camera_del(struct 
   soc_camera_device *icd)

static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
 .flags = SH_CEU_FLAG_USE_8BIT_BUS,
   + .max_width = 8188,
   + .max_height = 8188,
};

static struct resource ceu_resources[] = {
 
 On Sun, 8 Apr 2012, Guennadi Liakhovetski wrote:
 
  Now that MMC patches from this series are in the mainline, also 
  architecture patches can and should be applied. These are patches 5 and 6 
  from this series:
  
  http://article.gmane.org/gmane.linux.kernel.mmc/12748
  http://article.gmane.org/gmane.linux.ports.sh.devel/13535
  
  Would be good to have them in 3.4 since they fix modular MMC builds on 
  ag5evm and mackerel.
 
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #15589] 2.6.34-rc1: Badness at fs/proc/generic.c:316

2010-05-04 Thread Rafael J. Wysocki

On Wednesday 05 May 2010, Stefan Lippers-Hollmann wrote:
 Hi
 
 On Wednesday 05 May 2010, Rafael J. Wysocki wrote:
  This message has been generated automatically as a part of a summary report
  of recent regressions.
  
  The following bug entry is on the current list of known regressions
  from 2.6.33.  Please verify if it still should be listed and let the 
  tracking team
  know (either way).
  
  
  Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=15589
  Subject : 2.6.34-rc1: Badness at fs/proc/generic.c:316
  Submitter   : Christian Kujau li...@nerdbynature.de
  Date: 2010-03-13 23:53 (53 days old)
  Message-ID  : alpine.deb.2.01.1003131544340.5...@bogon.housecafe.de
  References  : http://marc.info/?l=linux-kernelm=126852442903680w=2
 
 Still valid for b2c2_flexcop_pci in 2.6.34-rc6-git2:
 
 [8.736930] Linux video capture interface: v2.00
 [8.809720] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver 
 chip loaded successfully
 [8.818680] flexcop-pci: will use the HW PID filter.
 [8.818685] flexcop-pci: card revision 2
 [8.818694] b2c2_flexcop_pci :06:01.0: PCI INT A - GSI 19 (level, 
 low) - IRQ 19
 [8.818794] [ cut here ]
 [8.818799] WARNING: at 
 /tmp/buildd/linux-sidux-2.6-2.6.34~rc6-git2/debian/build/source_amd64_none/fs/proc/generic.c:317
  __xlate_proc_name+0xb5/0xd0()
 [8.818801] Hardware name: EP45-DS3
 [8.818802] name 'Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver'
 [8.818804] Modules linked in: b2c2_flexcop_pci(+) cx88xx b2c2_flexcop 
 rfkill v4l2_common ir_common videodev drm snd_pcm snd_seq rtc_cmos snd_timer 
 rtc_core snd_seq_device rtc_lib v4l1_compat tveeprom v4l2_compat_ioctl32 
 ir_core dvb_core snd videobuf_dma_sg cx24123 cx24113 videobuf_core s5h1420 
 tpm_tis led_class btcx_risc tpm i2c_i801 i2c_algo_bit tpm_bios i2c_core evdev 
 intel_agp soundcore snd_page_alloc button processor ext4 mbcache jbd2 crc16 
 dm_mod sg sr_mod cdrom sd_mod usbhid hid uhci_hcd ahci firewire_ohci libata 
 firewire_core crc_itu_t ehci_hcd r8169 mii scsi_mod thermal usbcore nls_base 
 [last unloaded: scsi_wait_scan]
 [8.818832] Pid: 1064, comm: modprobe Not tainted 2.6.34-rc6-sidux-amd64 #1
 [8.818833] Call Trace:
 [8.818837]  [8104ba83] ? warn_slowpath_common+0x73/0xb0
 [8.818839]  [8104bb20] ? warn_slowpath_fmt+0x40/0x50
 [8.818842]  [8114f545] ? __xlate_proc_name+0xb5/0xd0
 [8.818844]  [8114fb2e] ? __proc_create+0x7e/0x150
 [8.818846]  [811504e7] ? proc_mkdir_mode+0x27/0x60
 [8.818849]  [8109fb55] ? register_handler_proc+0x115/0x130
 [8.818852]  [8109d4c1] ? __setup_irq+0x1d1/0x330
 [8.818855]  [a03bc160] ? flexcop_pci_isr+0x0/0x190 
 [b2c2_flexcop_pci]
 [8.818858]  [8109d735] ? request_threaded_irq+0x115/0x1b0
 [8.818860]  [a03bc495] ? flexcop_pci_probe+0x1a5/0x330 
 [b2c2_flexcop_pci]
 [8.818864]  [811ceef2] ? local_pci_probe+0x12/0x20
 [8.818867]  [811d02ca] ? pci_device_probe+0x10a/0x130
 [8.818870]  [8125cdda] ? driver_sysfs_add+0x5a/0x80
 [8.818872]  [8125cf03] ? driver_probe_device+0x93/0x190
 [8.818874]  [8125d093] ? __driver_attach+0x93/0xa0
 [8.818876]  [8125d000] ? __driver_attach+0x0/0xa0
 [8.818878]  [8125c638] ? bus_for_each_dev+0x58/0x80
 [8.818880]  [8125be70] ? bus_add_driver+0xb0/0x250
 [8.818882]  [8125d38a] ? driver_register+0x6a/0x130
 [8.818884]  [811d056c] ? __pci_register_driver+0x4c/0xc0
 [8.818887]  [a03bf000] ? flexcop_pci_module_init+0x0/0x20 
 [b2c2_flexcop_pci]
 [8.818890]  [81002044] ? do_one_initcall+0x34/0x1a0
 [8.818893]  [8107d15f] ? sys_init_module+0xdf/0x260
 [8.818896]  [81009f42] ? system_call_fastpath+0x16/0x1b
 [8.818897] ---[ end trace 46b5c98323696f39 ]---
 [8.822389] DVB: registering new adapter (FlexCop Digital TV device)
 [8.823874] b2c2-flexcop: MAC address = 00:d0:d7:0c:83:d6

Thanks for the update.

Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH/RESEND] soc-camera: add runtime pm support for subdevices

2010-02-08 Thread Rafael J. Wysocki

On Monday 08 February 2010, Guennadi Liakhovetski wrote:
 To save power soc-camera powers subdevices down, when they are not in use, 
 if this is supported by the platform. However, the V4L standard dictates, 
 that video nodes shall preserve configuration between uses. This requires 
 runtime power management, which is implemented by this patch. It allows 
 subdevice drivers to specify their runtime power-management methods, by 
 assigning a type to the video device.

You need a support for that at the bus type/device type/device class level,
because the core doesn't execute the driver callbacks directly.

Rafael

 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
 
 I've posted this patch to linux-media earlier, but I'd also like to get 
 comments on linux-pm, sorry to linux-media falks for a duplicate. To 
 explain a bit - soc_camera.c is a management module, that binds video 
 interfaces on SoCs and sensor drivers. The calls, that I am adding to 
 soc_camera.c shall save and restore sensor registers before they are 
 powered down and after they are powered up.
 
 diff --git a/drivers/media/video/soc_camera.c 
 b/drivers/media/video/soc_camera.c
 index 6b3fbcc..53201f3 100644
 --- a/drivers/media/video/soc_camera.c
 +++ b/drivers/media/video/soc_camera.c
 @@ -24,6 +24,7 @@
  #include linux/mutex.h
  #include linux/module.h
  #include linux/platform_device.h
 +#include linux/pm_runtime.h
  #include linux/vmalloc.h
  
  #include media/soc_camera.h
 @@ -387,6 +388,11 @@ static int soc_camera_open(struct file *file)
   goto eiciadd;
   }
  
 + pm_runtime_enable(icd-vdev-dev);
 + ret = pm_runtime_resume(icd-vdev-dev);
 + if (ret  0  ret != -ENOSYS)
 + goto eresume;
 +
   /*
* Try to configure with default parameters. Notice: this is the
* very first open, so, we cannot race against other calls,
 @@ -408,10 +414,12 @@ static int soc_camera_open(struct file *file)
   return 0;
  
   /*
 -  * First five errors are entered with the .video_lock held
 +  * First four errors are entered with the .video_lock held
* and use_count == 1
*/
  esfmt:
 + pm_runtime_disable(icd-vdev-dev);
 +eresume:
   ici-ops-remove(icd);
  eiciadd:
   if (icl-power)
 @@ -436,7 +444,11 @@ static int soc_camera_close(struct file *file)
   if (!icd-use_count) {
   struct soc_camera_link *icl = to_soc_camera_link(icd);
  
 + pm_runtime_suspend(icd-vdev-dev);
 + pm_runtime_disable(icd-vdev-dev);
 +
   ici-ops-remove(icd);
 +
   if (icl-power)
   icl-power(icd-pdev, 0);
   }
 @@ -1294,6 +1306,7 @@ static int video_dev_create(struct soc_camera_device 
 *icd)
   */
  static int soc_camera_video_start(struct soc_camera_device *icd)
  {
 + struct device_type *type = icd-vdev-dev.type;
   int ret;
  
   if (!icd-dev.parent)
 @@ -1310,6 +1323,9 @@ static int soc_camera_video_start(struct 
 soc_camera_device *icd)
   return ret;
   }
  
 + /* Restore device type, possibly set by the subdevice driver */
 + icd-vdev-dev.type = type;
 +
   return 0;
  }
  
 diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
 index dcc5b86..58b39a9 100644
 --- a/include/media/soc_camera.h
 +++ b/include/media/soc_camera.h
 @@ -282,4 +282,12 @@ static inline void soc_camera_limit_side(unsigned int 
 *start,
  extern unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link 
 *icl,
  unsigned long flags);
  
 +/* This is only temporary here - until v4l2-subdev begins to link to 
 video_device */
 +#include linux/i2c.h
 +static inline struct video_device *soc_camera_i2c_to_vdev(struct i2c_client 
 *client)
 +{
 + struct soc_camera_device *icd = client-dev.platform_data;
 + return icd-vdev;
 +}
 +
  #endif
 ___
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: suspend tree build warnings

2009-08-19 Thread Rafael J. Wysocki

On Wednesday 19 August 2009, Stephen Rothwell wrote:
 Hi Rafael,

Hi,

 Today's linux-next build (x86_64 allmodconfig) produced these warnings:
 
 drivers/media/dvb/frontends/dib7000p.c: In function 
 ‘dib7000p_i2c_enumeration’:
 drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of 2256 
 bytes is larger than 2048 bytes
 drivers/media/dvb/frontends/dib3000mc.c: In function 
 ‘dib3000mc_i2c_enumeration’:
 drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2160 
 bytes is larger than 2048 bytes
 
 Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 (PM:
 Introduce core framework for run-time PM of I/O devices (rev. 17)).

Well.

This commit increases the size of struct device quite a bit and both of the
drivers above create a state object on the stack that contains struct device
among other things.

I think they should allocate these objects using kmalloc() and I don't know
what I can do about this, really.  Maybe except for modifying the drivers to
use kmalloc().

Thanks,
Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sound, isapnp: allow building more drivers with COMPILE_TEST

Re: [trivial PATCH] treewide: Align function definition open/close braces

Re: [PATCH 2/8] Documentation: fix admin-guide doc refs

Re: [PATCH v10 00/24] Unified fwnode endpoint parser, async sub-device notifier support, N9 flash DTS

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

Re: [PATCH] media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[PATCH] media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN

Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN

Re: [PATCH, RFC 00/22] ARM randconfig bugs

Re: [PATCH v4] drm/exynos: prepare FIMD clocks

Re: outstanding ARM patches

Re: [Bug #15589] 2.6.34-rc1: Badness at fs/proc/generic.c:316

Re: [linux-pm] [PATCH/RESEND] soc-camera: add runtime pm support for subdevices

Re: linux-next: suspend tree build warnings

15 matches

Site Navigation

Mail list logo

Footer information