| Age | Commit message (Collapse) | Author |
|---|
|
If a driver consuming the GPIO chip is being probed at the same time as
the GPIO driver is registering the chip, it is possible for the
consuming driver to see the ->descs array in an uninitialised state.
For example, the gpio-keys-polled driver can fail like this:
kernel: gpiod_request: invalid GPIO (no device)
kernel: gpio-keys-polled PRP0001:07: failed to get gpio: -22
kernel: gpio-keys-polled: probe of PRP0001:07 failed with error -22
This patch makes gpiochip_add() hold the lock protecting gpio_devices
until it has finished setting desc->gdev on the newly inserted list
entry.
Signed-off-by: Dan Callaghan <dan.callaghan@opengear.com>
Link: https://lore.kernel.org/r/20200121001216.15964-1-dan.callaghan@opengear.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
This fixes some various typos.
Signed-off-by: Sachin Agarwal <asachin591@gmail.com>
Link: https://lore.kernel.org/r/20200118105319.68637-1-sachinagarwal@sachins-MacBook-2.local
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
platform_irq_count() and platform_get_irq() is the more generic
way (independent of device trees) to determine the count of available
interrupts. So use this instead.
As platform_irq_count() might return an error code (which
of_irq_count doesn't) some additional handling is necessary.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1576672860-14420-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
|
|
gpiochip_set_chained_irqchip() would assign a chained handler
to a GPIO chip. We now populate struct gpio_irq_chip for all
chained GPIO irqchips so drop this function.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200113220800.77817-1-linus.walleij@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
When input GPIO set from 0 to 1, the interrupt bit asserted in the GPIO
Interrupt Cause Register (ICR) even if the corresponding interrupt
masked in the GPIO Interrupt Mask Register.
Because interrupt mask register only affects assertion of the interrupt
bits in Main Interrupt Cause Register and it does not affect the
setting of bits in the GPIO ICR.
So, there is problem, when we unmask interrupt with already
asserted bit in the GPIO ICR, then false interrupt immediately occurs
even if GPIO don't change their value since last unmask.
Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com>
Link: https://lore.kernel.org/r/20200115073811.24438-1-bigunclemax@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The Imgu acronyms are moved from header file into Document by previous
commit b8726aea59de ("media: ipu3: update meta format documentation"), so
the item can be removed from TODO list now.
[Sakari Ailus: Use commit [0-9a-f]{12} plus subject]
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Print the node name during endpoint parsing for better debuggability.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Add the pinctrl driver support for i.MX8MP.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Link: https://lore.kernel.org/r/1579052348-32167-2-git-send-email-Anson.Huang@nxp.com
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
This reverts commit e878742c83ec26ef256ebb6b36a4d44644548f25.
Imgu should still keep the capability and flexibility to allow user to
run 2 video pipes, as the user may use the video pipe to capture still
frames with less system load and power than still pipe.
Suggested-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Add binding doc for i.MX8MP pinctrl driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1579052348-32167-1-git-send-email-Anson.Huang@nxp.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The mt9v111_def_fmt structure is only copied into another structure,
so make it const.
The opportunity for this change was found using Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Acked-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
In the current codes, the following 3 lines would be output to
the console for each irq line.
gpio gpiochip0: (gpio_thunderx): allocate IRQ 10, hwirq 0
gpio gpiochip0: (gpio_thunderx): found parent hwirq 245784
gpio gpiochip0: (gpio_thunderx): alloc_irqs_parent for 10 parent hwirq 245784
In general, there are about tens of irq lines for each gpio chip,
and then it would emit so many insignificant log in the boot process.
These infos are more suitable for the dbg purpose. So change these
to the dbg level. With this change, about 200 lines are suppressed
on my Marvell cn96xx board.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20200120095625.25164-1-haokexin@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel
intel-pinctrl for v5.6-1
* Tiger Lake appears to have _HID enumeration, thus driver has been updated
* Coffee Lake-S has the same IP as Sunrisepoint, thus ID has been added
* Baytrail has got more clean ups and bug fixes, such as direct IRQ handling
* Lynxpoint GPIO has been converted to true pin control driver
* The common driver now uses IRQ chip enumeration via GPIO chip
The following is an automated git shortlog grouped by driver:
baytrail:
- Replace WARN with dev_info_once when setting direct-irq pin to output
- Do not clear IRQ flags on direct-irq enabled pins
- Reuse struct intel_pinctrl in the driver
- Use local variable to keep device pointer
- Keep pointer to struct device instead of its container
- Use GPIO direction definitions
- Move IRQ valid mask initialization to a dedicated callback
- Group GPIO IRQ chip initialization
- Allocate IRQ chip dynamic
cherryview:
- Use GPIO direction definitions
intel:
- Pass irqchip when adding gpiochip
- Add GPIO <-> pin mapping ranges via callback
- Share struct intel_pinctrl for wider use
- Use GPIO direction definitions
lynxpoint:
- Update summary in the driver
- Switch to pin control API
- Add GPIO <-> pin mapping ranges via callback
- Implement ->pin_dbg_show()
- Add pin control operations
- Reuse struct intel_pinctrl in the driver
- Add pin control data structures
- Implement intel_gpio_get_direction callback
- Implement ->irq_ack() callback
- Move ownership check to IRQ chip
- Move lp_irq_type() closer to IRQ related routines
- Move ->remove closer to ->probe()
- Extract lp_gpio_acpi_use() for future use
- Convert unsigned to unsigned int
- Switch to memory mapped IO accessors
- Keep pointer to struct device instead of its container
- Relax GPIO request rules
- Assume 2 bits for mode selector
- Use standard pattern for memory allocation
- Use %pR to print IO resource
- Drop useless assignment
- Correct amount of pins
- Use raw_spinlock for locking
- Move GPIO driver to pin controller folder
sunrisepoint:
- Add Coffee Lake-S ACPI ID
- Add missing Interrupt Status register offset
tigerlake:
- Tiger Lake uses _HID enumeration
|
|
When submitting v2 of "fou: Support binding FoU socket" (1713cb37bf67),
I accidentally sent the wrong version of the patch and one fix was
missing. In the initial version of the patch, as well as the version 2
that I submitted, I incorrectly used ".type" for the two V6-attributes.
The correct is to use ".len".
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: 1713cb37bf67 ("fou: Support binding FoU socket")
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for v5.5
Second set of fixes for v5.5. There are quite a few patches,
especially on iwlwifi, due to me being on a long break. Libertas also
has a security fix and mt76 a build fix.
iwlwifi
* don't send the PPAG command when PPAG is disabled, since it can cause problems
* a few fixes for a HW bug
* a fix for RS offload;
* a fix for 3168 devices where the NVM tables where the wrong tables were being read
* fix a couple of potential memory leaks in TXQ code
* disable L0S states in all hardware since our hardware doesn't
officially support them anymore (and older versions of the hardware
had instability in these states)
* remove lar_disable parameter since it has been causing issues for
some people who erroneously disable it
* force the debug monitor HW to stop also when debug is disabled,
since it sometimes stays on and prevents low system power states
* don't send IWL_MVM_RXQ_NSSN_SYNC notification due to DMA problems
libertas
* fix two buffer overflows
mt76
* build fix related to CONFIG_MT76_LEDS
* fix off by one in bitrates handling
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Keys queued for measurement should be freed if a custom IMA policy
was not loaded. Otherwise, the keys will remain queued forever
consuming kernel memory.
This patch defines a delayed workqueue to handle the above scenario.
The workqueue handler is setup to execute 5 minutes after IMA
initialization is completed.
If a custom IMA policy is loaded before the workqueue handler is
scheduled to execute, the workqueue task is cancelled and any queued keys
are processed for measurement. But if a custom policy was not loaded then
the queued keys are just freed when the delayed workqueue handler is run.
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Reported-by: kernel test robot <rong.a.chen@intel.com> # sleeping
function called from invalid context
Reported-by: kbuild test robot <lkp@intel.com> # redefinition of
ima_init_key_queue() function.
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Measuring keys requires a custom IMA policy to be loaded. Keys should
be queued for measurement if a custom IMA policy is not yet loaded.
Keys queued for measurement, if any, should be processed when a custom
policy is loaded.
This patch updates the IMA hook function ima_post_key_create_or_update()
to queue the key if a custom IMA policy has not yet been loaded. And,
ima_update_policy() function, which is called when a custom IMA policy
is loaded, is updated to process queued keys.
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
|
|
Measuring keys requires a custom IMA policy to be loaded. Keys created
or updated before a custom IMA policy is loaded should be queued and
will be processed after a custom policy is loaded.
This patch defines a workqueue for queuing keys when a custom IMA policy
has not yet been loaded. An intermediate Kconfig boolean option namely
IMA_QUEUE_EARLY_BOOT_KEYS is used to declare the workqueue functions.
A flag namely ima_process_keys is used to check if the key should be
queued or should be processed immediately.
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
|
|
All rtd->dai_link callback functions are controlled by soc_rtd_xxxx(),
and checking rtd->dai_link->ops.
We don't need to have null_snd_soc_ops anymore.
This patch removes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhegl3oz.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add soc_rtd_trigger() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871rrsmi9j.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add soc_rtd_hw_free() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736c8mi9n.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add soc_rtd_hw_params() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kwomi9r.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add soc_rtd_prepare() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875zh4mi9v.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add soc_rtd_shutdown() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877e1kmi9z.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add soc_rtd_startup() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878sm0mia4.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
mediatek jpeg codec driver can depend on MTK_IOMMU or MTK_IOMMU_V1
Signed-off-by: Maoguang Meng <maoguang.meng@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
This device does not function correctly in raw mode in kernel
versions validating buffer sizes in bulk mode. It erroneously
announces 16 bits per pixel instead of 12 for NV12 format, so it
needs this quirk to fix computed frame size and avoid legitimate
frames getting discarded.
[Move info and div variables to local scope]
Signed-off-by: Sergey Zakharchenko <szakharchenko@digital-loggers.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Way back in 2017, fuzzing the 4.14-rc2 USB stack with syzkaller kicked
up the following WARNING from the UVC chain scanning code:
| list_add double add: new=ffff880069084010, prev=ffff880069084010,
| next=ffff880067d22298.
| ------------[ cut here ]------------
| WARNING: CPU: 1 PID: 1846 at lib/list_debug.c:31 __list_add_valid+0xbd/0xf0
| Modules linked in:
| CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted
| 4.14.0-rc2-42613-g1488251d1a98 #238
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
| Workqueue: usb_hub_wq hub_event
| task: ffff88006b01ca40 task.stack: ffff880064358000
| RIP: 0010:__list_add_valid+0xbd/0xf0 lib/list_debug.c:29
| RSP: 0018:ffff88006435ddd0 EFLAGS: 00010286
| RAX: 0000000000000058 RBX: ffff880067d22298 RCX: 0000000000000000
| RDX: 0000000000000058 RSI: ffffffff85a58800 RDI: ffffed000c86bbac
| RBP: ffff88006435dde8 R08: 1ffff1000c86ba52 R09: 0000000000000000
| R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069084010
| R13: ffff880067d22298 R14: ffff880069084010 R15: ffff880067d222a0
| FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000
| CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
| CR2: 0000000020004ff2 CR3: 000000006b447000 CR4: 00000000000006e0
| Call Trace:
| __list_add ./include/linux/list.h:59
| list_add_tail+0x8c/0x1b0 ./include/linux/list.h:92
| uvc_scan_chain_forward.isra.8+0x373/0x416
| drivers/media/usb/uvc/uvc_driver.c:1471
| uvc_scan_chain drivers/media/usb/uvc/uvc_driver.c:1585
| uvc_scan_device drivers/media/usb/uvc/uvc_driver.c:1769
| uvc_probe+0x77f2/0x8f00 drivers/media/usb/uvc/uvc_driver.c:2104
Looking into the output from usbmon, the interesting part is the
following data packet:
ffff880069c63e00 30710169 C Ci:1:002:0 0 143 = 09028f00 01030080
00090403 00000e01 00000924 03000103 7c003328 010204db
If we drop the lead configuration and interface descriptors, we're left
with an output terminal descriptor describing a generic display:
/* Output terminal descriptor */
buf[0] 09
buf[1] 24
buf[2] 03 /* UVC_VC_OUTPUT_TERMINAL */
buf[3] 00 /* ID */
buf[4] 01 /* type == 0x0301 (UVC_OTT_DISPLAY) */
buf[5] 03
buf[6] 7c
buf[7] 00 /* source ID refers to self! */
buf[8] 33
The problem with this descriptor is that it is self-referential: the
source ID of 0 matches itself! This causes the 'struct uvc_entity'
representing the display to be added to its chain list twice during
'uvc_scan_chain()': once via 'uvc_scan_chain_entity()' when it is
processed directly from the 'dev->entities' list and then again
immediately afterwards when trying to follow the source ID in
'uvc_scan_chain_forward()'
Add a check before adding an entity to a chain list to ensure that the
entity is not already part of a chain.
Link: https://lore.kernel.org/linux-media/CAAeHK+z+Si69jUR+N-SjN9q4O+o5KFiNManqEa-PjUta7EOb7A@mail.gmail.com/
Cc: <stable@vger.kernel.org>
Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Add NPCM Peripheral SPI reset binding documentation,
Removing unnecessary aliases use.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200115162301.235926-4-tmaimon77@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This is initial amplifier driver for rt1015.
Signed-off-by: Jack Yu <jack.yu@realtek.com>
Link: https://lore.kernel.org/r/20200115112519.22050-1-jack.yu@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200122104559.17043-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The code which checks the return value for snd_soc_add_dai_link() call
in soc_tplg_fe_link_create() moved the snd_soc_add_dai_link() call before
link->dobj members initialization.
While it does not affect the latest kernels, the old soc-core.c code
in the stable kernels is affected. The snd_soc_add_dai_link() function uses
the link->dobj.type member to check, if the link structure is valid.
Reorder the link->dobj initialization to make things work again.
It's harmless for the recent code (and the structure should be properly
initialized before other calls anyway).
The problem is in stable linux-5.4.y since version 5.4.11 when the
upstream commit 76d270364932 was applied.
Fixes: 76d270364932 ("ASoC: topology: Check return value for snd_soc_add_dai_link()")
Cc: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20200122190752.3081016-1-perex@perex.cz
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Definitions for idisp snd_soc_dai_links within skl_hda_dsp_common are
missing platform component. Add it to address following bug reported by
KASAN:
[ 10.538502] BUG: KASAN: global-out-of-bounds in skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp]
[ 10.538509] Write of size 8 at addr ffffffffc0606840 by task systemd-udevd/299
(...)
[ 10.538519] Call Trace:
[ 10.538524] dump_stack+0x62/0x95
[ 10.538528] print_address_description+0x2f5/0x3b0
[ 10.538532] ? skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp]
[ 10.538535] __kasan_report+0x134/0x191
[ 10.538538] ? skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp]
[ 10.538542] ? skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp]
[ 10.538544] kasan_report+0x12/0x20
[ 10.538546] __asan_store8+0x57/0x90
[ 10.538550] skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp]
[ 10.538553] platform_drv_probe+0x51/0xb0
[ 10.538556] really_probe+0x311/0x600
[ 10.538559] driver_probe_device+0x87/0x1b0
[ 10.538562] device_driver_attach+0x8f/0xa0
[ 10.538565] ? device_driver_attach+0xa0/0xa0
[ 10.538567] __driver_attach+0x102/0x1a0
[ 10.538569] ? device_driver_attach+0xa0/0xa0
[ 10.538572] bus_for_each_dev+0xe8/0x160
[ 10.538574] ? subsys_dev_iter_exit+0x10/0x10
[ 10.538577] ? preempt_count_sub+0x18/0xc0
[ 10.538580] ? _raw_write_unlock+0x1f/0x40
[ 10.538582] driver_attach+0x2b/0x30
[ 10.538585] bus_add_driver+0x251/0x340
[ 10.538588] driver_register+0xd3/0x1c0
[ 10.538590] __platform_driver_register+0x6c/0x80
[ 10.538592] ? 0xffffffffc03e8000
[ 10.538595] skl_hda_audio_init+0x1c/0x1000 [snd_soc_skl_hda_dsp]
[ 10.538598] do_one_initcall+0xd0/0x36a
[ 10.538600] ? trace_event_raw_event_initcall_finish+0x160/0x160
[ 10.538602] ? kasan_unpoison_shadow+0x36/0x50
[ 10.538605] ? __kasan_kmalloc+0xcc/0xe0
[ 10.538607] ? kasan_unpoison_shadow+0x36/0x50
[ 10.538609] ? kasan_poison_shadow+0x2f/0x40
[ 10.538612] ? __asan_register_globals+0x65/0x80
[ 10.538615] do_init_module+0xf9/0x36f
[ 10.538619] load_module+0x398e/0x4590
[ 10.538625] ? module_frob_arch_sections+0x20/0x20
[ 10.538628] ? __kasan_check_write+0x14/0x20
[ 10.538630] ? kernel_read+0x9a/0xc0
[ 10.538632] ? __kasan_check_write+0x14/0x20
[ 10.538634] ? kernel_read_file+0x1d3/0x3c0
[ 10.538638] ? cap_capable+0xca/0x110
[ 10.538642] __do_sys_finit_module+0x190/0x1d0
[ 10.538644] ? __do_sys_finit_module+0x190/0x1d0
[ 10.538646] ? __x64_sys_init_module+0x50/0x50
[ 10.538649] ? expand_files+0x380/0x380
[ 10.538652] ? __kasan_check_write+0x14/0x20
[ 10.538654] ? fput_many+0x20/0xc0
[ 10.538658] __x64_sys_finit_module+0x43/0x50
[ 10.538660] do_syscall_64+0xce/0x700
[ 10.538662] ? syscall_return_slowpath+0x230/0x230
[ 10.538665] ? __do_page_fault+0x51e/0x640
[ 10.538668] ? __kasan_check_read+0x11/0x20
[ 10.538670] ? prepare_exit_to_usermode+0xc7/0x200
[ 10.538673] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: a78959f407e6 ("ASoC: Intel: skl_hda_dsp_common: use modern dai_link style")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200122181254.22801-1-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Both the data and clock should be connected to both the left and right
inputs for DMIC only inputs, add the missing routes.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200122104143.16725-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The RK3399 variant does not have postproc_regs declared,
this can cause a NULL pointer dereference trying to decode:
[ 89.331359] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 89.352804] Call trace:
[ 89.353191] hantro_postproc_disable+0x20/0xe8 [hantro_vpu]
[ 89.354056] hantro_start_prepare_run+0x58/0x68 [hantro_vpu]
[ 89.354923] hantro_h264_dec_prepare_run+0x30/0x6f0 [hantro_vpu]
[ 89.355846] rk3399_vpu_h264_dec_run+0x1c/0x14a8 [hantro_vpu]
[ 89.356748] device_run+0xa4/0xb8 [hantro_vpu]
Fix this by adding a NULL check in hantro_postproc_enable/disable.
Fixes: 8c2d66b036c7 ("media: hantro: Support color conversion via post-processing")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
When aligning the format the pixel format that is being processed shall
be used to figure out alignment constraints, not the currently active
pixel format. The alignment might be part of a try operation and shall
not be effected by the active format. Fix this by looking at the correct
pixel format.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Although in the most platforms, the power of eeprom are alway
on, some platforms disable the eeprom power in order to meet
low power request. This patch add the pm_runtime ops to control
power to support all platforms.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
[Bartosz: rebased on top of current at24/for-next]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
|
In some platforms, they disable the power-supply of eeprom due
to power consumption reduction. This patch add vcc-supply property.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
|
There are spelling mistakes in dev_err messages. Fix them.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200122093818.2800743-1-colin.king@canonical.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200122235237.2830344-1-colin.king@canonical.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Update the help text to reflect current support devices:
1. The Exynos high speed I2C driver supports Exynos5 (ARMv7), Exynos5433
and Exynos7 (both ARMv8) SoCs,
2. The S3C I2C driver supports S3C, S5Pv210 and Exynos{3,4,5} SoCs.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Some of the I2C bus drivers can be compile tested to increase build
coverage. This requires also:
1. Adding dependencies on COMMON_CLK for BCM2835 and Meson I2C
controllers,
2. Adding 'if' conditional to 'default y' so they will not get enabled
by default on all other architectures,
3. Limiting few compile test options to supported architectures (which
provide the readsX()/writesX() primitives).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
[wsa: revert chunk for ZX2967. it needs more preparation]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
