Added generic pin configuration and multiplexing support,
and should be preferred than brcm legacy one.
Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Newer versions of the firmware for the Qualcomm Datacenter Technologies
QDF2400 restricts access to a subset of the GPIOs on the TLMM. To
prevent older kernels from accidentally accessing the restricted GPIOs,
we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002,
and introduce a new property "gpios". This property is an array of
specific GPIOs that are accessible. When an older kernel boots on
newer (restricted) firmware, it will fail to probe.
To implement the sparse GPIO map, we register all of the GPIOs, but
fill in the data only for available GPIOs. This ensures that the driver
cannot accidentally access an unavailable GPIO.
The pinctrl-msm driver also scans the "gpios" property to determine
which pins are available, and ensure that only those can be registered.
Support for QCOM8001 is removed as there is no longer any firmware that
implements it.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Two data structures are declared as static globals but are intended to
be per-TLMM. Move them into the msm_pinctrl structure and initialize
them at runtime.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add pinctrl driver for Actions Semi S900 SoC. The driver supports
pinctrl, pinmux and pinconf functionalities through a range of registers
common to both gpio driver and pinctrl driver.
Pinmux functionality is available only for the pin groups while the
pinconf functionality is available for both pin groups and individual
pins.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds a samsung_pin_dbg_show function to implement the
pin_dbg_show callback function which can be used to show pin
confuration values. Basically, it can show pin setting values by
accessing the "pins" node like below:
$ cat pins
pin 0 (gpy7-0) CON(0x0) DAT(0x1) PUD(0x1) DRV(0x0) CON_PDN(0x0) PUD_PDN(0x0)
Signed-off-by: Chanho Park <parkch98@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It turns out that the Windows GPIO driver for Sunrisepoint PCH-H uses
similar bank structure than it does for Cannon Lake with the exception
that here the bank size is always 24 pins. Starting from pad group E the
BIOS/Windows GPIO numbering does not match the hardware anymore but
instead there are gaps to make each pad group ("bank") consume exactly
24 pins. Because of this Linux does not use correct pins for
GpioIo/GpioIo resources exposed by the BIOS.
This patch aligns the GPIO number space with BIOS/Windows to make sure
the same numbering scheme is used in Linux as well following what we did
already for Intel Cannon Lake.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1543769
Reported-by: Vivien FRASCA <vivien.frasca@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When we dropped the custom Linux GPIO translation it resulted that the
IRQ numbers changed slightly as well. Normally this would be fine
because everyone is expected to use controller relative GPIO numbers and
ACPI GpioIo/GpioInt resources. However, there is a certain set of
Intel_Strago based Chromebooks where i8042 keyboard controller IRQ
number is hardcoded be 182 (this is corrected with newer coreboot but
the older ones still have the hardcoded Linux IRQ number). Because of
this hardcoded IRQ number keyboard on those systems accidentally broke
again.
Fix this by iteratively associating IRQ descriptors to the chip irqdomain
so that there are no gaps on those systems. Other systems are not
affected.
Fixes: 03c4749dd6 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199463
Reported-by: Sultan Alsawaf <sultanxda@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIOAO bank is range from GPIOAO_0 to GPIOAO_13.
Fixes: 83c566806a ("pinctrl: meson-axg: Add new pinctrl driver for Meson AXG SoC")
Reported-by: Xingyu Chen <xingyu.chen@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Trivial fix to spelling mistake in status text string
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Add a null check for ghes_pvt, before dereferencing it. The pointer
could still be null in case the return path is taken before initialising
ghes_pvt in the registration function.
Reviewed-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: lkml <linux-kernel@vger.kernel.org>
Link: http://lkml.kernel.org/r/1524737809-24475-1-git-send-email-sughosh.ganu@arm.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Tony reported seeing
"Internal error: Can't find EDAC structure"
when injecting correctable errors due to the fact that ghes_edac would
still load even if the whitelist won't hit. Drop the pr_err() in
ghes_edac_report_mem_error() for now due to the hacky way how ghes_edac
depends on ghes.c.
While at it, make ghes_edac_register() return an error if it doesn't hit
in the whitelist as it is the only sensible thing to do in that
situation.
Furthermore, move the call to it to happen last in ghes_probe() so that
GHES initializing properly does not depend on ghes_edac init at all
as latter is only reporting errors and not required for GHES's proper
functioning.
Reviewed-by: Toshi Kani <toshi.kani@hpe.com>
Tested-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20180420182015.zao3olss4tvvlxki@agluck-desk
On some devices the "AC" interface ACPI AML code uses the exact same broken
logic which is causing the battery code to wrongly report discharging to
determine the "AC" state. Specifically the ACPI AML code is checking the
charging status bits of the charger-IC rather then the vbus present or
power-good status bits.
This makes our workaround for devices which wrongly report discharging when
plugged into AC while the charge is above the start charging threshold not
work on these devices.
This commit adds a battery_ac_is_broken flag and when that is set it skips
the power_supply_is_system_supplied() check in the workaround fixing this.
This flag gets set by a DMI quirk selected by systems where we know the AC
AML code is broken in this way *and* the rate_now value can be trusted.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On quite a few devices the battery code in the ACPI tables is buggy and
first checks the charging status bits of the charger-IC, and if those
report not charging it will report discharging, without looking at the
presence of AC power or at the battery dis(charge) current from the
fuel-gauge.
This causes the wrong status to be reported for the battery in the
following quite common scenario:
1) Plug in charger while battery is say half full, battery starts
charging, charging state bits indicate: pre-charge or fast-charge,
ACPI reported battery status is ok
2) When fully charged charging state bits indicate: end-of-charge,
ACPI reported battery status is ok
3) unplug the charger, wait 1 minute, replug. Now the battery voltage is
still above the start-charging threshold, so the charger will not start
charging to avoid wrecking the battery by repeatedly recharging the last 1%
capacity. The charger IC charging state bits now are all 0 (not-charging)
and the broken ACPI code wrongly translate this to "discharging" and ends
up setting the ACPI_BATTERY_STATE_DISCHARGING bit in its state field.
Reporting this "not charging" state as discharging is confusing for users,
making the user think his adapter/power-brick is broken or not properly
plugged in.
This commit adds a helper for handling the ACPI_BATTERY_STATE_DISCHARGING
state. This helper checks if we're an AC and the current going out of the
battery is 0 and in that case reports a status of "not charging" to
userspace rather then "discharging".
This replaces commit c68f0676ef ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA"), a previous fix for this which was reverted.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The battery code does not use the dmi_system_id ident member, so there is
no need to initialize it. This saves us storing the unused strings as
as const data.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ac.c code does not use the dmi_system_id ident member, so there is
no need to initialize it. This saves us storing the unused "thinkpad e530"
string as const data.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
...and restore reverse xmas tree while at it.
Signed-off-by: Laszlo Toth <laszlth@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The old wait_on_atomic_t used a custom callback to perform the
schedule(), which used my return semantics of reporting an error code on
timeout. wait_var_event_timeout() uses the schedule() return semantics
of reporting the remaining jiffies (1 if it timed out with 0 jiffies
remaining!) and 0 on failure. This semantic mismatch lead to us falsely
claiming a time out occurred.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106085
Fixes: d224985a5e ("sched/wait, drivers/drm: Convert wait_on_atomic_t() usage to the new wait_var_event() API")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417170638.20550-1-chris@chris-wilson.co.uk
Use i915.dmc_firmware_path to override default firmware for the platform
and bypassing version checks.
v2: add missing param struct member declaration (David)
Tested-by: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Acked-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180424122016.2416-1-jani.nikula@intel.com
An incremental send operation can miss a truncate operation when an inode
has an increased size in the send snapshot and a prealloc extent beyond
its size.
Consider the following scenario where a necessary truncate operation is
missing in the incremental send stream:
1) In the parent snapshot an inode has a size of 1282957 bytes and it has
no prealloc extents beyond its size;
2) In the the send snapshot it has a size of 5738496 bytes and has a new
extent at offsets 1884160 (length of 106496 bytes) and a prealloc
extent beyond eof at offset 6729728 (and a length of 339968 bytes);
3) When processing the prealloc extent, at offset 6729728, we end up at
send.c:send_write_or_clone() and set the @len variable to a value of
18446744073708560384 because @offset plus the original @len value is
larger then the inode's size (6729728 + 339968 > 5738496). We then
call send_extent_data(), with that @offset and @len, which in turn
calls send_write(), and then the later calls fill_read_buf(). Because
the offset passed to fill_read_buf() is greater then inode's i_size,
this function returns 0 immediately, which makes send_write() and
send_extent_data() do nothing and return immediately as well. When
we get back to send.c:send_write_or_clone() we adjust the value
of sctx->cur_inode_next_write_offset to @offset plus @len, which
corresponds to 6729728 + 18446744073708560384 = 5738496, which is
precisely the the size of the inode in the send snapshot;
4) Later when at send.c:finish_inode_if_needed() we determine that
we don't need to issue a truncate operation because the value of
sctx->cur_inode_next_write_offset corresponds to the inode's new
size, 5738496 bytes. This is wrong because the last write operation
that was issued started at offset 1884160 with a length of 106496
bytes, so the correct value for sctx->cur_inode_next_write_offset
should be 1990656 (1884160 + 106496), so that a truncate operation
with a value of 5738496 bytes would have been sent to insert a
trailing hole at the destination.
So fix the issue by making send.c:send_write_or_clone() not attempt
to send write or clone operations for extents that start beyond the
inode's size, since such attempts do nothing but waste time by
calling helper functions and allocating path structures, and send
currently has no fallocate command in order to create prealloc extents
at the destination (either beyond a file's eof or not).
The issue was found running the test btrfs/007 from fstests using a seed
value of 1524346151 for fsstress.
Reported-by: Gu, Jinxiang <gujx@cn.fujitsu.com>
Fixes: ffa7c4296e ("Btrfs: send, do not issue unnecessary truncate operations")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In preivous patch:
Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist
We avoid starting btrfs transaction and get this information from
fs_info->running_transaction directly.
When accessing running_transaction in check_delayed_ref, there's a
chance that current transaction will be freed by commit transaction
after the NULL pointer check of running_transaction is passed.
After looking all the other places using fs_info->running_transaction,
they are either protected by trans_lock or holding the transactions.
Fix this by using trans_lock and increasing the use_count.
Fixes: e4c3b2dcd1 ("Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist")
CC: stable@vger.kernel.org # 4.14+
Signed-off-by: ethanwu <ethanwu@synology.com>
Signed-off-by: David Sterba <dsterba@suse.com>
dm644x_init_devices() is unnecessarily implemented as a
postcore_initcall().
This does not cause any issues now, but creates issues when
converting to common clock framework where clocks themselves
become platform devices and are initialized later. Because of
this, device clock acquisition and runtime PM on that device
fails.
Move the call to .init_machine() callback along with rest of
platform device's registration.
While at it, convert it to return void since return value is
ignored by caller anyway.
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
All platforms now use the core_chipsel field in platform_data. Stop
using pdev->id in the aemif code.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
All platform now use the core_chipsel field in platform data. Stop
using pdev->id in the driver.
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We have the 'ti,davinci-chipselect' property in the device tree, but
when using platform data the driver silently uses the id field of
struct platform_device as the chipselect. This is confusing and we
almost broke the nand support again recently after converting the
platform to common clock framework (which changed the device id in the
clock lookup - the problem is gone now that we no longer acquire the
clock in the nand driver.
This patch adds a new field - core_chipsel - to the platform_data.
Subsequent patches will convert the platforms to using this new field.
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that
I2C can correctly lookup the recovery gpios.
Note that it is the gpio-davinci driver that sets the gpiochip label to
davinci_gpio.0.
Also, the I2C device uses an id of 1 on DM644x and DM355.
While at it, convert to using GPIO_TO_PIN() for referring to GPIO pin
numbers, like it is done in rest of the board support files.
Fixes: e535376537 ("i2c/ARM: davinci: Deep refactoring of I2C recovery")
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Convert boilerplate license statement into proper SPDX identifier style.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Using plain jiffies in error state output makes the output
time differences relative to the current system time. This
is wrong as it makes output time differences dependent
of when the error state is printed rather than when it is
captured.
Store capture jiffies into error state and use it
when outputting the state to fix time differences output.
v2: use engine timestamp as epoch, output formatting (Chris)
v3: pass epoch to print_engine/request (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180430075259.4476-1-mika.kuoppala@linux.intel.com
- Switch to inline member docs for dma_fence_ops.
- Mild polish all around.
- hyperlink all the things!
v2: - Remove the various [in] annotations, they seem really uncommon
in kerneldoc and look funny.
v3: Linebreak the "Returns" part of the @fill_driver_data kerneldoc
(Eric).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180427061724.28497-2-daniel.vetter@ffwll.ch
Use a radix tree to provide a map between the secid and the label,
and along with it a basic ability to provide secctx conversion.
Shared/cached secctx will be added later.
Signed-off-by: John Johansen <john.johansen@canonical.com>
The canonical compatible string is "atmel,maxtouch", let's use it. Also,
change the node name to be "touchscreen" rather than driver name.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
If we get an invalid device configuration from a palm 3 type device, we
might incorrectly parse things, and we have the potential to crash in
"interesting" ways.
Fix this up by verifying the size of the configuration passed to us by
the device, and only if it is correct, will we handle it.
Note that this also fixes an information leak of slab data.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ johan: add comment about the info leak ]
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Add CAAM support on i.MX6UL.
Also, since CAAM is not available on i.MX6ULL the CAAM node
needs to be deleted in the imx6ull.dtsi.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
This patch adds support for ublox R410M PID 0x90b2 USB modem to option
driver, this module supports LTE Cat M1 / NB1.
Interface layout:
0: QCDM/DIAG
1: ADB
2: AT
3: RMNET
Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
The dwm-158 interface 4 and 5 doesn't answer to the AT commands
and doesn't appears a option interface.
Tested on openwrt distribution (kernel 4.14 using the old blacklist
definitions).
Lars Melin also writes:
Blacklisting interface 4 and 5 is correct because:
MI_00 D-Link Mobile Broadband Device (cdc_ether)
MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp modem)
MI_03 D-Link HSPA+DataCard NMEA Device
MI_04 D-Link HSPA+DataCard Speech Port
MI_05 D-Link HSPA+DataCard Debug Port
MI_06 USB Mass Storage Device
Signed-off-by: Giuseppe Lippolis <giu.lippolis@gmail.com>
[ johan: add Lars's comment on the interface layout and reword summary ]
Cc: Lars Melin <larsm17@gmail.com>
Cc: Dan Williams <dcbw@redhat.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
The DP-MST support requires more PCM streams than usual, hence
CONFIG_SND_DYNAMIC_MINORS is almost mandatory. Currently the driver
just warns and continues even if streams are missing, but it doesn't
seem to enough convince users to switch to the modern setup.
This patch adds the enforced selection of CONFIG_SND_DYNAMIC_MINORS
from CONFIG_SND_HDA_CODEC_HDMI for covering that.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
