aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMarek Vasut <marek.vasut@mailbox.org>2025-10-11 12:59:53 +0200
committerDmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>2025-10-11 19:38:20 +0300
commitdb74b04edce1bc86b9a5acc724c7ca06f427ab60 (patch)
tree4f25aa4c18093ad2a67e86e1723c114ebcb09887
parentdrm/panthor: Ensure MCU is disabled on suspend (diff)
downloadlinux-db74b04edce1bc86b9a5acc724c7ca06f427ab60.tar.gz
linux-db74b04edce1bc86b9a5acc724c7ca06f427ab60.zip
drm/bridge: lt9211: Drop check for last nibble of version register
There is now a new LT9211 rev. U5, which reports chip ID 0x18 0x01 0xe4 . The previous LT9211 reported chip ID 0x18 0x01 0xe3 , which is what the driver checks for right now. Since there is a possibility there will be yet another revision of the LT9211 in the future, drop the last version nibble check to allow all future revisions of the chip to work with this driver. This fix makes LT9211 rev. U5 work with this driver. Fixes: 8ce4129e3de4 ("drm/bridge: lt9211: Add Lontium LT9211 bridge driver") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251011110017.12521-1-marek.vasut@mailbox.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
-rw-r--r--drivers/gpu/drm/bridge/lontium-lt9211.c3
1 files changed, 1 insertions, 2 deletions
diff --git a/drivers/gpu/drm/bridge/lontium-lt9211.c b/drivers/gpu/drm/bridge/lontium-lt9211.c
index 399fa7eebd49..03fc8fd10f20 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9211.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9211.c
@@ -121,8 +121,7 @@ static int lt9211_read_chipid(struct lt9211 *ctx)
}
/* Test for known Chip ID. */
- if (chipid[0] != REG_CHIPID0_VALUE || chipid[1] != REG_CHIPID1_VALUE ||
- chipid[2] != REG_CHIPID2_VALUE) {
+ if (chipid[0] != REG_CHIPID0_VALUE || chipid[1] != REG_CHIPID1_VALUE) {
dev_err(ctx->dev, "Unknown Chip ID: 0x%02x 0x%02x 0x%02x\n",
chipid[0], chipid[1], chipid[2]);
return -EINVAL;
7a05476446f15269b714ce4cc&follow=1'>git-tag.txt: Add a missing hyphen to `-s`Wieland Hoffmann1-1/+1 Signed-off-by: Wieland Hoffmann <themineo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-10-01daemon: remove write-only variable maxfdRené Scharfe1-4/+0 It became unused when 6573faff (NO_IPV6 support for git daemon) replaced select() with poll(). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-10-01daemon: fix error message after bind()René Scharfe1-1/+1 Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-10-01daemon: handle gethostbyname() errorRené Scharfe1-13/+14 If the user-supplied hostname can't be found then we should not use it. We already avoid doing that in the non-NO_IPV6 case by checking if the return value of getaddrinfo() is zero (success). Do the same in the NO_IPV6 case and make sure the return value of gethostbyname() isn't NULL before dereferencing this pointer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-29Git 2.1.2v2.1.2Junio C Hamano4-3/+24 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-25l10n: de.po: use comma before "um"Phillip Sz1-43/+43 This patch adds a comma before the "um". See: http://www.duden.de/sprachwissen/rechtschreibregeln/komma#K117 Signed-off-by: Phillip Sz <phillip.szelat@gmail.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 2014-09-25l10n: de.po: change Email to E-MailPhillip Sz1-7/+7 Change all Email to E-Mail, as this is the correct form in German. Signed-off-by: Phillip Sz <phillip.szelat@gmail.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 2014-09-25po/TEAMS: add new member to German translation teamRalf Thielow1-0/+1 Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 2014-09-22mailinfo: work around -Wstring-plus-int warningEric Sunshine1-1/+2 The just-released Apple Xcode 6.0.1 has -Wstring-plus-int enabled by default which complains about pointer arithmetic applied to a string literal: builtin/mailinfo.c:303:24: warning: adding 'long' to a string does not append to the string return !memcmp(SAMPLE + (cp - line), cp, strlen(SAMPLE) ... ~~~~~~~^~~~~~~~~~~~~ Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-19Git 2.1.1v2.1.1Junio C Hamano4-3/+48 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-16Documentation/git-rebase.txt: <upstream> must be given to specify <branch>Sergey Organov1-1/+1 Current syntax description makes one wonder if there is any syntactic way to distinguish between <branch> and <upstream> so that one can specify <branch> but not <upstream>, but that is not the case. Make it explicit that these arguments are positional, i.e. the earlier ones cannot be omitted if you want to give later ones. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-16mailinfo: make ">From" in-body header check more robustJeff King6-1/+65 Since commit 81c5cf7 (mailinfo: skip bogus UNIX From line inside body, 2006-05-21), we have treated lines like ">From" in the body as headers. This makes "git am" work for people who erroneously paste the whole output from format-patch: From 12345abcd...fedcba543210 Mon Sep 17 00:00:00 2001 From: them Subject: [PATCH] whatever into their email body (assuming that an mbox writer then quotes "From" as ">From", as otherwise we would actually mailsplit on the in-body line). However, this has false positives if somebody actually has a commit body that starts with "From "; in this case we erroneously remove the line entirely from the commit message. We can make this check more robust by making sure the line actually looks like a real mbox "From" line. Inspect the line that begins with ">From " a more carefully to only skip lines that match the expected pattern (note that the datestamp part of the format-patch output is designed to be kept constant to help those who write magic(5) entries). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-12fsck: return non-zero status on missing ref tipsJeff King2-1/+58 Fsck tries hard to detect missing objects, and will complain (and exit non-zero) about any inter-object links that are missing. However, it will not exit non-zero for any missing ref tips, meaning that a severely broken repository may still pass "git fsck && echo ok". The problem is that we use for_each_ref to iterate over the ref tips, which hides broken tips. It does at least print an error from the refs.c code, but fsck does not ever see the ref and cannot note the problem in its exit code. We can solve this by using for_each_rawref and noting the error ourselves. In addition to adding tests for this case, we add tests for all types of missing-object links (all of which worked, but which we were not testing). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-11config: avoid a funny sentinel value "a^"Jeff King3-7/+21 Introduce CONFIG_REGEX_NONE as a more explicit sentinel value to say "we do not want to replace any existing entry" and use it in the implementation of "git config --add". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-10fsck: exit with non-zero status upon error from fsck_obj()Jeff King3-8/+29 Upon finding a corrupt loose object, we forgot to note the error to signal it with the exit status of the entire process. [jc: adjusted t1450 and added another test] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-09-03reachable.c: add HEAD to reachability starting commitsMax Kirillov2-0/+25 HEAD is not explicitly used as a starting commit for calculating reachability, so if it's detached and reflogs are disabled it may be pruned. Add tests which demonstrate it. Test 'prune: prune former HEAD after checking out branch' also reverts changes to repository. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-29index-pack: fix race condition with duplicate basesJeff King1-2/+31 When we are resolving deltas in an indexed pack, we do it by first selecting a potential base (either one stored in full in the pack, or one created by resolving another delta), and then resolving any deltas that use that base. When we resolve a particular delta, we flip its "real_type" field from OBJ_{REF,OFS}_DELTA to whatever the real type is. We assume that traversing the objects this way will visit each delta only once. This is correct for most packs; we visit the delta only when we process its base, and each object (and thus each base) appears only once. However, if a base object appears multiple times in the pack, we will try to resolve any deltas based on it once for each instance. We can detect this case by noting that a delta we are about to resolve has already had its real_type field flipped, and we already do so with an assert(). However, if multiple threads are in use, we may race with another thread on comparing and flipping the field. We need to synchronize the access. The right mechanism for doing this is a compare-and-swap (we atomically "claim" the delta for our own and find out whether our claim was successful). We can implement this in C by using a pthread mutex to protect the operation. This is not the fastest way of doing a compare-and-swap; many processors provide instructions for this, and gcc and other compilers provide builtins to access them. However, some experiments showed that lock contention does not cause a significant slowdown here. Adding c-a-s support for many compilers would increase the maintenance burden (and we would still end up including the pthread version as a fallback). Note that we only need to touch the OBJ_REF_DELTA codepath here. An OBJ_OFS_DELTA object points to its base using an offset, and therefore has only one base, even if another copy of that base object appears in the pack (we do still touch it briefly because the setting of real_type is factored out of resolve_data). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-29fast-import: fix segfault in store_tree()Maxim Bublis2-3/+7 Branch tree is NULLified by filedelete command if we are trying to delete root tree. Add sanity check and use load_tree() in that case. Signed-off-by: Maxim Bublis <satori@yandex-team.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-29t9300: test filedelete commandMaxim Bublis1-0/+104 Add new fast-import test series for filedelete command. Signed-off-by: Maxim Bublis <satori@yandex-team.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-29po/TEAMS: add new members to German translation teamRalf Thielow1-0/+2 Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 2014-08-29l10n: de.po: translate 38 new messagesRalf Thielow1-1359/+1513 Translate 38 new messages came from git.pot update in fe05e19 (l10n: git.pot: v2.1.0 round 1 (38 new, 9 removed)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 2014-08-28Document LF appearing in shallow command during send-pack/receive-packShawn Pearce1-1/+1 The implementation sends an LF, but the protocol documentation was missing this detail. Signed-off-by: Shawn Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-26send-pack: take refspecs over stdinJeff King5-2/+153 Pushing a large number of refs works over most transports, because we implement send-pack as an internal function. However, it can sometimes fail when pushing over http, because we have to spawn "git send-pack --stateless-rpc" to do the heavy lifting, and we pass each refspec on the command line. This can cause us to overflow the OS limits on the size of the command line for a large push. We can solve this by giving send-pack a --stdin option and using it from remote-curl. We already dealt with this on the fetch-pack side in 078b895 (fetch-pack: new --stdin option to read refs from stdin, 2012-04-02). The stdin option (and in particular, its use of packet-lines for stateless-rpc input) is modeled after that solution. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-25checkout -m: attempt merge when deletion of path was stagedJonathan Nieder2-5/+23 twoway_merge() is missing an o->gently check in the case where a file that needs to be modified is missing from the index but present in the old and new trees. As a result, in this case 'git checkout -m' errors out instead of trying to perform a merge. Fix it by checking o->gently. While at it, inline the o->gently check into reject_merge to prevent future call sites from making the same mistake. Noticed by code inspection. The test for the motivating case was added by JC. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-25git-prompt: do not look for refs/stash in $GIT_DIRJeff King1-1/+2 Since dd0b72c (bash prompt: use bash builtins to check stash state, 2011-04-01), git-prompt checks whether we have a stash by looking for $GIT_DIR/refs/stash. Generally external programs should never do this, because they would miss packed-refs. That commit claims that packed-refs does not pack refs/stash, but that is not quite true. It does pack the ref, but due to a bug, fails to prune the ref. When we fix that bug, we would want to be doing the right thing here. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-25fast-import: fix buffer overflow in dump_tagsJeff King1-4/+6 When creating a new annotated tag, we sprintf the refname into a static-sized buffer. If we have an absurdly long tagname, like: git init repo && cd repo && git commit --allow-empty -m foo && git tag -m message mytag && git fast-export mytag | perl -lpe '/^tag/ and s/mytag/"a" x 8192/e' | git fast-import <input we'll overflow the buffer. We can fix it by using a strbuf. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-25fast-import: clean up pack_data pointer in end_packfileJeff King1-4/+7 We have a global pointer pack_data pointing to the current pack we have open. Inside end_packfile we have two new pointers, old_p and new_p. The latter points to pack_data, and the former points to the new "installed" version of the packfile we get when we hand the file off to the regular sha1_file machinery. When then free old_p. Presumably the extra old_p pointer was there so that we could overwrite pack_data with new_p and still free old_p, but we don't do that. We just leave pack_data pointing to bogus memory, and don't overwrite it until we call start_packfile again (if ever). This can cause problems for our die routine, which calls end_packfile to clean things up. If we die at the wrong moment, we can end up looking at invalid memory in pack_data left after the last end_packfile(). Instead, let's make sure we set pack_data to NULL after we free it, and make calling endfile() again with a NULL pack_data a noop (there is nothing to end). We can further make things less confusing by dropping old_p entirely, and moving new_p closer to its point of use. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-25pack-refs: prune top-level refs like "refs/foo"Jeff King2-1/+9 After we have packed all refs, we prune any loose refs that correspond to what we packed. We do so by first taking a lock with lock_ref_sha1, and then deleting the loose ref file. However, lock_ref_sha1 will refuse to take a lock on any refs that exist at the top-level of the "refs/" directory, and we skip pruning the ref. This is almost certainly not what we want to happen here. The criteria to be pruned should not differ from that to be packed; if a ref makes it to prune_ref, it's because we want it both packed and pruned (if there are refs you do not want to be packed, they should be omitted much earlier by pack_ref_is_possible, which we do in this case if --all is not given). We can fix this by switching to lock_any_ref_for_update. This behaves exactly the same with the exception of this top-level check. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-08-23l10n: de.po: improve message when switching branchesRalf Thielow1-3/+3 Suggested-by: Stefan Beller <stefanbeller@gmail.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 2014-08-23l10n: de.po: fix typoRalf Thielow1-2/+2 Reported-by: Hartmut Henkel Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 2014-08-22po/TEAMS: Add Catalan teamAlex Henrie1-0/+4 Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>