There is no point in zeroing 'buf'.
It would be cleared only once, and if the 'while' loop is executed several
times, all but the first run would have a 'dirty' buffer.
Moreover, the size of the chunk is computed in the loop and this size is
passed to xdbc_bulk_write().
So remove this useless memset().
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/687bbcd940c59fbddd0e3a8b578fd3422962e50f.1675016180.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If xdbc_bulk_write() fails, the values in 'buf' can be anything. So the
string is not guaranteed to be NULL terminated when xdbc_trace() is called.
Reserve an extra byte, which will be zeroed automatically because 'buf' is
a static variable, in order to avoid troubles, should it happen.
Fixes: aeb9dd1de9 ("usb/early: Add driver for xhci debug capability")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/d6a7562c5e839a195cee85db6dc81817f9372cb1.1675016180.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Samsung Exynos SoC USB 3.0 DWC3 Controller is a simple wrapper of
actual DWC3 Controller device node. It handles necessary Samsung
Exynos-specific resources (regulators, clocks), but does not have its
own MMIO address space.
However neither simple-bus bindings nor dtc W=1 accept device nodes in
soc@ node which do not have unit address.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230127211748.260718-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
devm_platform_get_and_ioremap_resource() never returns NULL pointer,
it will return ERR_PTR() when it fails, so replace the check with
IS_ERR().
Fixes: baef5330d3 ("usb: fotg210: Acquire memory resource in core")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230130120633.3342285-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Parse the width-mm and height-mm devicetree properties of the panel node,
and use this to set the DRM Display Mode instead of calculating it
based on a hardcoded DPI.
Signed-off-by: Rayyan Ansari <rayyan@ansari.sh>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230126182435.70544-2-rayyan@ansari.sh
Cleanup by removing unneeded quotes from refs and
add maxItems to reset-gpios and fix the required list.
Fixes: 31360c28df ("dt-bindings: usb: Add binding for Via lab VL817 hub controller")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230130084744.2539-5-linux.amoon@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A USB peripheral can respond with a NAK if it is not yet ready to
send/receive data. In this case, the transaction should be retried. The
MAX3421 driver did do this, and switched to a different type of retry
after a number of 'fast' retries. On at least some USB flash devices,
this second type of retry never succeeds. This patch changes the
behaviour so that 'fast' retries continue.
Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20230127024734.8777-1-mark.tomlinson@alliedtelesis.co.nz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Few Qualcomm SoCs require minimum performance level of power domain, so
allow it:
sm8550-mtp.dtb: usb@a6f8800: 'required-opps' does not match any of the regexes: '^usb@[0-9a-f]+$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230127121122.342191-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nothing was explicitly bounds checking the priority index used to access
clpriop[]. WARN and bail out early if it's pathological. Seen with GCC 13:
../net/sched/sch_htb.c: In function 'htb_activate_prios':
../net/sched/sch_htb.c:437:44: warning: array subscript [0, 31] is outside array bounds of 'struct htb_prio[8]' [-Warray-bounds=]
437 | if (p->inner.clprio[prio].feed.rb_node)
| ~~~~~~~~~~~~~~~^~~~~~
../net/sched/sch_htb.c:131:41: note: while referencing 'clprio'
131 | struct htb_prio clprio[TC_HTB_NUMPRIO];
| ^~~~~~
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Cong Wang <cong.wang@bytedance.com>
Link: https://lore.kernel.org/r/20230127224036.never.561-kees@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
We have two types for UUIDs depending on the byte ordering.
Instead of explaining how bytes should go over the wire,
use dedicated APIs and data types. This removes a confusion
over the byte ordering.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-By: Jó Ágila Bitsch <jgilab@gmail.com>
Link: https://lore.kernel.org/r/20230125143425.85268-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There doesn't appear to be a reason to truncate the allocation used for
flow_info, so do a full allocation and remove the unused empty struct.
GCC does not like having a reference to an object that has been
partially allocated, as bounds checking may become impossible when
such an object is passed to other code. Seen with GCC 13:
../drivers/net/ethernet/mediatek/mtk_ppe.c: In function 'mtk_foe_entry_commit_subflow':
../drivers/net/ethernet/mediatek/mtk_ppe.c:623:18: warning: array subscript 'struct mtk_flow_entry[0]' is partly outside array bounds of 'unsigned char[48]' [-Warray-bounds=]
623 | flow_info->l2_data.base_flow = entry;
| ^~
Cc: Felix Fietkau <nbd@nbd.name>
Cc: John Crispin <john@phrozen.org>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Mark Lee <Mark-MC.Lee@mediatek.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230127223853.never.014-kees@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Do the customary s/dev_priv/i915/ rename and aliasing
'dev' pointer removal. Though various register definitions
still depend on the magic 'dev_priv' variable so not
a 100% conversion.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Previously, ibmvnic IRQs were assigned to CPU numbers by assigning all
the IRQs for transmit queues then assigning all the IRQs for receive
queues. With multi-threaded processors, in a heavy RX or TX environment,
physical cores would either be overloaded or underutilized (due to the
IRQ assignment algorithm). This approach is sub-optimal because IRQs for
the same subprocess (RX or TX) would be bound to adjacent CPU numbers,
meaning they were more likely to be contending for the same core.
For example, in a system with 64 CPU's and 32 queues, the IRQs would
be bound to CPU in the following pattern:
IRQ type | CPU number
-----------------------
TX0 | 0-1
TX1 | 2-3
<etc>
RX0 | 32-33
RX1 | 34-35
<etc>
Observe that in SMT-8, the first 4 tx queues would be sharing the
same core.
A more optimal algorithm would balance the number RX and TX IRQ's across
the physical cores. Therefore, to increase performance, distribute RX and
TX IRQs across cores by alternating between assigning IRQs for RX and TX
queues to CPUs.
With a system with 64 CPUs and 32 queues, this results in the following
pattern:
IRQ type | CPU number
-----------------------
TX0 | 0-1
RX0 | 2-3
TX1 | 4-5
RX1 | 6-7
<etc>
Observe that in SMT-8, there is equal distribution of RX and TX IRQs
per core. In the above case, each core handles 2 TX and 2 RX IRQ's.
Signed-off-by: Nick Child <nnac123@linux.ibm.com>
Reviewed-by: Haren Myneni <haren@linux.ibm.com>
Link: https://lore.kernel.org/r/20230127214358.318152-1-nnac123@linux.ibm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
At the moment, accel drivers can be built-in even with CONFIG_DRM=m,
but this causes a link failure:
x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_dev_init':
ivpu_drv.c:(.text+0x1535): undefined reference to `drmm_kmalloc'
x86_64-linux-ld: ivpu_drv.c:(.text+0x1562): undefined reference to `drmm_kmalloc'
x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_remove':
ivpu_drv.c:(.text+0x1faa): undefined reference to `drm_dev_unregister'
x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_probe':
ivpu_drv.c:(.text+0x1fef): undefined reference to `__devm_drm_dev_alloc'
The problem is that DRM_ACCEL is a 'bool' symbol, so driver that
only depend on DRM_ACCEL but not also on DRM do not see the restriction
to =m configs.
To ensure that each accel driver has an implied dependency on CONFIG_DRM,
enclose the entire Kconfig file in an if/endif check.
Fixes: 8bf4889762 ("drivers/accel: define kconfig and register a new major")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127221504.2522909-1-arnd@kernel.org
It was reported that we might get a hung and loss of register access in
some cases when CDCLK PLL is disabled and then enabled, while squashing
is enabled.
As a workaround it was proposed by HW team that SW should disable squashing
when CDCLK PLL is being reenabled.
v2: - Added WA number comment(Rodrigo Vivi)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130135836.12738-1-stanislav.lisovskiy@intel.com
When CONFIG_MODULE_SIG_KEY is PKCS#11 URI (pkcs11:*), signing of modules
fails:
scripts/sign-file sha256 /.../linux/pkcs11:token=foo;object=bar;pin-value=1111 certs/signing_key.x509 /.../kernel/crypto/tcrypt.ko
Usage: scripts/sign-file [-dp] <hash algo> <key> <x509> <module> [<dest>]
scripts/sign-file -s <raw sig> <hash algo> <x509> <module> [<dest>]
First, we need to avoid adding the $(srctree)/ prefix to the URL.
Second, since the kconfig string values no longer include quotes, we need to add
them again when passing a PKCS#11 URI to sign-file. This avoids
splitting by the shell if the URI contains semicolons.
Fixes: 4db9c2e3d0 ("kbuild: stop using config_filename in scripts/Makefile.modsign")
Fixes: 129ab0d2d9 ("kbuild: do not quote string values in include/config/auto.conf")
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When CONFIG_MODULE_SIG_KEY is PKCS#11 URI (pkcs11:*) and contains a
semicolon, signing_key.x509 fails to build:
certs/extract-cert pkcs11:token=foo;object=bar;pin-value=1111 certs/signing_key.x509
Usage: extract-cert <source> <dest>
Add quotes to the extract-cert argument to avoid splitting by the shell.
This approach was suggested by Masahiro Yamada <masahiroy@kernel.org>.
Fixes: 129ab0d2d9 ("kbuild: do not quote string values in include/config/auto.conf")
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since v4l2_fill_fmtdesc will be called in the ioctl v4l_enum_fmt anyway.
We can set the format description and compressed flag from v4l_fill_fmtdesc
and can remove the extra name field in uvc_format_desc.
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20230126231456.3402323-6-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the uvc_fmts array can not be modified we declare it const and
change every user of the uvc_format_by_guid function aswell.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20230126231456.3402323-5-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The media driver USB_VIDEO_CLASS and USB_F_UVC are using the same
function uvc_format_by_guid. Since the function is inline, every user
will get a copy of the used uvc_fmts array and the function. This patch
moves the code to an own compile unit and add this dependency as
UVC_COMMON to both users.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20230126231456.3402323-4-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the headerfile is only used in usb devices it is better
placed with the other usb files.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20230126231456.3402323-3-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Cypress EZUSB FX3 UVC example can be configured to report pixel
format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for
BGRA/X 8:8:8:8.
The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420.
This seems to be an extension documented in the Microsoft Windows Media
Format SDK[2]. This Media Format SDK defines this GUID as corresponding
to `MEDIASUBTYPE_RGB32`, which is confirmed by [4] as `MEDIASUBTYPE_ARGB32`
has different GUID.
Note that in my case, the FX3 UVC can output either channel order,
BGR or RGB or any other mix for that matter. Since Linux commit
1b8dc32286 ("[media] uvcvideo: Add GUID for BGR 8:8:8")
defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep
this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well.
Document [3] also indicates the channel order is BGR.
[1] https://www.usb.org/document-library/video-class-v15-document-set
[2] https://learn.microsoft.com/en-us/windows/win32/wmformat/media-type-identifiers
[3] https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes
[4] https://gix.github.io/media-types/
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Ricardo Ribalda <ricardo@ribalda.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20230126231456.3402323-2-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iJgEABYKAEAWIQTAnvhxs4J7QT+XHKnMPy2AAyfeZAUCY8R0CCIcbGF1cmVudC5w
aW5jaGFydEBpZGVhc29uYm9hcmQuY29tAAoJEMw/LYADJ95k3XwBAMn3MAcX185i
DNPc1tWKCA0+j7eLqgCrNHOQgqYSV7ZOAQDaoDt/drJffp8S9TdCpP1DhT9wcSIB
i6i6j7mlzGsqBw==
=yAlT
-----END PGP SIGNATURE-----
Merge tag 'media-uvc-next-20230115' of git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into usb-next
Merge in this tag from the media tree so that future USB uvc patches
will apply properly.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'media-uvc-next-20230115' of git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux: (27 commits)
media: uvcvideo: Silence memcpy() run-time false positive warnings
media: uvcvideo: Quirk for autosuspend in Logitech B910 and C910
media: uvcvideo: Fix race condition with usb_kill_urb
media: uvcvideo: Use standard names for menus
media: uvcvideo: Fix power line control for Lenovo Integrated Camera
media: uvcvideo: Refactor power_line_frequency_controls_limited
media: uvcvideo: Refactor uvc_ctrl_mappings_uvcXX
media: uvcvideo: Implement mask for V4L2_CTRL_TYPE_MENU
media: uvcvideo: Extend documentation of uvc_video_clock_decode()
media: uvcvideo: Limit power line control for Acer EasyCamera
media: uvcvideo: Refactor __uvc_ctrl_add_mapping
media: uvcvideo: Fix handling on Bitmask controls
media: uvcvideo: Do not return positive errors in uvc_query_ctrl()
media: uvcvideo: Return -EACCES for Wrong state error
media: uvcvideo: Improve error logging in uvc_query_ctrl()
media: uvcvideo: Check for INACTIVE in uvc_ctrl_is_accessible()
media: uvcvideo: Factor out usb_string() calls
media: uvcvideo: Limit power line control for Acer EasyCamera
media: uvcvideo: Recover stalled ElGato devices
media: uvcvideo: Remove void casting for the status endpoint
...
Fix two mistakes in the PCM interface section:
1/ Members of the snd_pcm_hardware structure are channels_{min,max}
and not channel_{min,max} (mind the 's').
2/ Another sentence is incomplete as the reference to one structure
member (period_bytes_max) is missing.
There is no relevant 'Fixes:' tag to apply as both typos predate the
Git era.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230130162924.119389-1-miquel.raynal@bootlin.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Smatch static analysis tool detects that acquired lock is not released
in hwdep device when condition branch is passed due to no event. It is
unlikely to occur, while fulfilling is preferable for better coding.
Reported-by: Dan Carpenter <error27@gmail.com>
Fixes: 634ec0b290 ("ALSA: firewire-motu: notify event for parameter change in register DSP model")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230130141540.102854-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The function local variable, curr_cycle_time is declared without
initialization. When tracepoints event is not probed, it looks to be
used as is. This commit fixes it. Fortunately, the value of local variable
is not used unless the event is probed, thus this commit is for better
coding.
Reported-by: Dan Carpenter <error27@gmail.com>
Fixes: fef4e61b0b ("ALSA: firewire-lib: extend tracepoints event including CYCLE_TIME of 1394 OHCI")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230130141532.102838-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
1. Correct s3c64xx_set_timer_source() prototype.
2. Re-work MIPI and DP phys as children of Exynos PMU system controller.
This both better reflects actual device hierarchy and allows to
remove later few warnings from dtc W=1 and dtbs_check.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmPWgyoQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD1zm5D/0SnGyimYCVmaE1GeiWOSAZgnN2XQ4YEx++
Qa77zf6CSWVhjQVberlIswfjFI+Qmv4lVk5Z2OOJbIVRhP9fDS0dI/Q5kMwrQfRf
c5Bh+orG2f/8HgeHy1P0PdZO9QbW+irUWZ8utxmBRQedwLlkD8MkiOG/H0Bclo8z
RKiOYdqsVe4y7LHuZBfUL8yFIEdhF4HWL9iMsCftwnEpzr4ImCr7djMlxV1QtsLC
f25klrZYOwX8jUKjI5IaDS+/MW70qWNMO/grYnaGpTfxMrxdWKIQ7P1vfeOfbsCi
aEahnWw0tn7YTqZoLv3IoMJbWCtRs0jcXK+bUvssSa/1mM3FpP9fK/psvB37j9u6
SzWzjutgiJV1VeqXiKRlrbV9+QaS9WvVFV4br/GV3ZzlmB+vIJWQVdD61vlrn1EY
xLiaJ2Q478r8qoAQOHaUGPxWHA+wf3f/nMAHo5eIb4eepwUZIuaONlReH1ekeLHq
VyAJKqy/Yl/a3kvUvDvd/2oXdUC8PJVPjFCN7gbXfTJOx1JosSB3O0+oOKo9vKx5
2P1j3GTyPZu0YzjcK29h7p2y8HTsR5BDXS1uCv45pJRnnR1XqeNM1ZdsdskDn8oQ
wzT10cXnxoArVkEleflPTar4ThWTxJYOdiWxLcLpl//Xzyn1aDDZ5qg8gjmUHZj+
IzRARtncUw==
=RHCU
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmPYzdcACgkQmmx57+YA
GNkTixAAv5PHBohbDoy8c2BJe24sJI1EfVI1xs28F9XvVD8vGXOcPBONkAQpWM+U
rWSPhQx78xbL8pR2lDaCvrxwBiTcqUcuzPYM6NvdazXFh7QiHUEW5TBKTZ2Rw11i
8diS5hUyFq1ulszftjB2GoTZMOiVyFaJksdgbf6z6gFcilz1kFUUyODnKM7uHOvk
V9P+/RLY0yccUrhm+l+dUaTGnvUubtuT+9afIB7uJi/44rz91XxdiYcBr98R2p2e
aXc5eGGgGf0m32yL01RQSfx5x898MSzpsd8/FKEEJ7n2lBtNuXmByknNPk1StZXQ
jcN4Fv0QFgYRnm40A/VUdIsMTCBXMMuyxAw/w/ZMV3l32GH7VEsYLEMZKSm0tAFy
ZGzaqCnbwZbNzmIYqLSGMNeAmTlVR2T5sCkfpVH3zTKhN8JIYoIer2kCByFMFKmb
PK7AzFqnpgVapEeheBkBMOBfQ3qquzaHRFjo5jxG593SMRcB25NGH/5O2ZdlYPZn
GZL2UF4+HjHCC58VZzKjAWqqtYxWlNjmX27W6F8s51a6vZBRzFDkTsKL2evpblHA
rQmb7urOc1tr0UGLCbCaIp6elDJ8ZawfzBigOJlK0O7C1VXgEm0pmCpFgpA7n6fL
lZAZ65wqDzucAvQ+WC7Hb3Gpa1Pk8N5avq3ZO5807M2EPMCFCME=
=+4aK
-----END PGP SIGNATURE-----
Merge tag 'samsung-soc-6.3' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc
Samsung mach/soc changes for v6.3
1. Correct s3c64xx_set_timer_source() prototype.
2. Re-work MIPI and DP phys as children of Exynos PMU system controller.
This both better reflects actual device hierarchy and allows to
remove later few warnings from dtc W=1 and dtbs_check.
* tag 'samsung-soc-6.3' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
dt-bindings: soc: samsung: exynos-pmu: allow phys as child
ARM: s3c: fix s3c64xx_set_timer_source prototype
Link: https://lore.kernel.org/r/20230129143944.5104-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The soc_bus code pokes around in the internal bus structures assuming
that it "knows" if a field is not set that it has not been registered
yet. That isn't a safe assumption, so just remove the layering
violation entirely and keep track if the bus has been registered or not
ourselves.
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20230130171059.1784057-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
please pull the following:
- Stefan enables the necessary configuration options to make use of the
framebuffer on Raspberry Pi devices
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmPVeEYACgkQh9CWnEQH
BwRvuRAAjJ0ZpYewUS71QjO7RdthbxCIuuA5UW75VzYE8GpRD2sOQRrBaQkpRR7i
9Gd/09xUq2NBY/DXdtwirNBmDP0oFDzF6mN8MzmydM+3gHPJoICg0SwR/Aey6sLf
pNEnAfhZ+cglTY6Lzuy3Tz851/Bqc18S1txQyEcKtHx2y8F1tkhj6FO17PxO9184
+Cq4B9XU7PIF6tMOyOVvhXf8ptl3Fy0XCnjDzcxb4XHpk1kbIxDqkvF5CVPtlo13
/lcsr0LPZ0Yb56w/6iBiiAjKFCIlImV4kLzSYqRSV0Ku7Ec2cKca/mt0uGrGBY1d
AZ4q+10hgcd4+Nq7cybiKa3mhFvh5jTQWrq0rD75c5UtEa3kwAr7croOcltT/X5h
VTWcQgqilOp3akGctNdZM87pIGYdk1xDk9teUwlM9DebhlHr9+nXbHIgR5Yv3KCO
z5NTsV6C67/Gh66RoBajwHclDySRST+m0C1Gf0FeF9dwk7pFZV9B9byovhcX1bD/
wKugbYcBY/ufrSZ/0wHsT04CRN1st4pMSxbJ/9uU8OAaOwMX0/bV9ivmmQPE3jSi
G7Y/YX4JkqYFgrcbK9xSGCSke3pHGOjTe+XB25A2F8YqGMi21Yx6yHmk0xqWEXUJ
GvpIPTQei11pSZ92kLf0+ocPaesBTXAaU+JmgtmF1JELj8RXpM8=
=s2GZ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmPYzFYACgkQmmx57+YA
GNlRHBAAxJnMK4F/vRvbwvKVgLs+YnlqeiyvvKWeX6iNFO+F6OUZGiuVgCq9azfP
C63tc7wkZr2zGkIOejqZPkpUxxkzTZztywO44dpx2/U1aTIdPTL/9xIKAGmNQY5B
XQ9YEEkgiNnenZR8pOf3YsxFjsjuR4IBenlnXxd+840qv4Hr0mu2OgJDGwy3CpBp
Bh/cBJZC/yhtn0NhIvU95gwDBk2MncWTSWVOsZEytDUxMShuTfjnWrV+GDJ66bz+
1RcWKjktOIV9OWm4zG3x6ZTvfWvVqrUC5n80FKr/W+3NSm7H/1WeLobqVP61wEAG
9ojlkrk4VvH2aruotD07Q+AGuMe9yai1lmG+e3Xxr5oj9hoyvpfp/CV4AM4WFAzg
kufmEfZo+chueaA6EZmoKU/CCFc3V01CzOWrWaytXk30BVh4zwSyEYLnvFDXcFOk
OYz+lmt0Cca9IVSYy7Ls5Y2qv6BQkxUUgJUJmp9WpXaXgJ9UFdz7lcAl9UcTyLwd
0b9vVdDKB5kGmP9DB5t5PPWkpQkvBVbj73lCJeNVP+JjjDjedD5skp6HGfnF97RJ
Sm0fHtnDMA5lG+cHcu/pahcSpKsDxkw9vf7DXPiWCbGk6kvYkuVbc3l/aejb+Ltc
hmWY0gE4gbZd63zrUlStDe7DCfmQICKAWKJzeNa2HfWSACsl//U=
=564E
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.3/defconfig' of https://github.com/Broadcom/stblinux into soc/defconfig
This pull request contains Broadcom ARM SoCs defconfig updates for 6.3,
please pull the following:
- Stefan enables the necessary configuration options to make use of the
framebuffer on Raspberry Pi devices
* tag 'arm-soc/for-6.3/defconfig' of https://github.com/Broadcom/stblinux:
ARM: bcm2835_defconfig: Switch to SimpleDRM
ARM: bcm2835_defconfig: Enable the framebuffer
Link: https://lore.kernel.org/r/20230128193823.1628716-1-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
cc2520 supports both probing from static platform_data and
from devicetree, but there have never been any definitions
of the platform data in the mainline kernel, so it's safe
to assume that only the DT path is used.
After folding cc2520_platform_data into the driver itself,
the GPIO handling can be simplified by moving to the modern
gpiod interface.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230126161658.2983292-1-arnd@kernel.org
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
