aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/i2c/i2c-mux.c
diff options
context:
space:
mode:
authorDave Airlie <airlied@redhat.com>2018-11-29 10:21:23 +1000
committerDave Airlie <airlied@redhat.com>2018-11-29 10:28:49 +1000
commit61647c77cb15354a329cbb36fe7a2253b36b51b1 (patch)
tree59d887f99bc4a2bdddc7cfc1d81794c2a4cdc759 /drivers/i2c/i2c-mux.c
parentMerge tag 'du-next-20181123' of git://linuxtv.org/pinchartl/media into drm-next (diff)
parentdrm/vkms: Drop custom vkms_dumb_map(). (diff)
downloadlinux-61647c77cb15354a329cbb36fe7a2253b36b51b1.tar.gz
linux-61647c77cb15354a329cbb36fe7a2253b36b51b1.zip
Merge tag 'drm-misc-next-2018-11-28' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v4.21: Core Changes: - Merge drm_info.c into drm_debugfs.c - Complete the fake drm_crtc_commit's hw_done/flip_done sooner. - Remove deprecated drm_obj_ref/unref functions. All drivers use get/put now. - Decrease stack use of drm_gem_prime_mmap. - Improve documentation for dumb callbacks. Driver Changes: - Add edid support to virtio. - Wait on implicit fence in meson and sun4i. - Add support for BGRX8888 to sun4i. - Preparation patches for sun4i driver to start supporting linear and tiled YUV formats. - Add support for HDMI 1.4 4k modes to meson, and support for VIC alternate timings. - Drop custom dumb_map in vkms. - Small fixes and cleanups to v3d. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/151a3270-b1be-ed75-bd58-6b29d741f592@linux.intel.com
Diffstat (limited to 'drivers/i2c/i2c-mux.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-18 11:57:50 +0000
2:47:56 -0700'>2015-06-01Sixth batch for 2.5 cycleJunio C Hamano1-1/+50 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-27t7063: hide stderr from setup inside prereqJeff King1-2/+6 When t7063 starts, it runs "update-index --untracked-cache" to see if we support the untracked cache. Its output goes straight to stderr, even if the test is not run with "-v". Let's wrap it in a prereq that will hide the output by default, but show it with "-v". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-26Git 2.4.2v2.4.2Junio C Hamano4-3/+49 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-26Fifth batch for 2.5 cycleJunio C Hamano1-6/+28 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-25http-backend: spool ref negotiation requests to bufferJeff King3-11/+105 When http-backend spawns "upload-pack" to do ref negotiation, it streams the http request body to upload-pack, who then streams the http response back to the client as it reads. In theory, git can go full-duplex; the client can consume our response while it is still sending the request. In practice, however, HTTP is a half-duplex protocol. Even if our client is ready to read and write simultaneously, we may have other HTTP infrastructure in the way, including the webserver that spawns our CGI, or any intermediate proxies. In at least one documented case[1], this leads to deadlock when trying a fetch over http. What happens is basically: 1. Apache proxies the request to the CGI, http-backend. 2. http-backend gzip-inflates the data and sends the result to upload-pack. 3. upload-pack acts on the data and generates output over the pipe back to Apache. Apache isn't reading because it's busy writing (step 1). This works fine most of the time, because the upload-pack output ends up in a system pipe buffer, and Apache reads it as soon as it finishes writing. But if both the request and the response exceed the system pipe buffer size, then we deadlock (Apache blocks writing to http-backend, http-backend blocks writing to upload-pack, and upload-pack blocks writing to Apache). We need to break the deadlock by spooling either the input or the output. In this case, it's ideal to spool the input, because Apache does not start reading either stdout _or_ stderr until we have consumed all of the input. So until we do so, we cannot even get an error message out to the client. The solution is fairly straight-forward: we read the request body into an in-memory buffer in http-backend, freeing up Apache, and then feed the data ourselves to upload-pack. But there are a few important things to note: 1. We limit the in-memory buffer to prevent an obvious denial-of-service attack. This is a new hard limit on requests, but it's unlikely to come into play. The default value is 10MB, which covers even the ridiculous 100,000-ref negotation in the included test (that actually caps out just over 5MB). But it's configurable on the off chance that you don't mind spending some extra memory to make even ridiculous requests work. 2. We must take care only to buffer when we have to. For pushes, the incoming packfile may be of arbitrary size, and we should connect the input directly to receive-pack. There's no deadlock problem here, though, because we do not produce any output until the whole packfile has been read. For upload-pack's initial ref advertisement, we similarly do not need to buffer. Even though we may generate a lot of output, there is no request body at all (i.e., it is a GET, not a POST). [1] http://article.gmane.org/gmane.comp.version-control.git/269020 Test-adapted-from: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-22upload-pack: optionally allow fetching reachable sha1Fredrik Medley6-6/+97 With uploadpack.allowReachableSHA1InWant configuration option set on the server side, "git fetch" can make a request with a "want" line that names an object that has not been advertised (likely to have been obtained out of band or from a submodule pointer). Only objects reachable from the branch tips, i.e. the union of advertised branches and branches hidden by transfer.hideRefs, will be processed. Note that there is an associated cost of having to walk back the history to check the reachability. This feature can be used when obtaining the content of a certain commit, for which the sha1 is known, without the need of cloning the whole repository, especially if a shallow fetch is used. Useful cases are e.g. repositories containing large files in the history, fetching only the needed data for a submodule checkout, when sharing a sha1 without telling which exact branch it belongs to and in Gerrit, if you think in terms of commits instead of change numbers. (The Gerrit case has already been solved through allowTipSHA1InWant as every Gerrit change has a ref.) Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-22upload-pack: prepare to extend allow-tip-sha1-in-wantFredrik Medley2-10/+19 To allow future extensions, e.g. allowing non-tip sha1, replace the boolean allow_tip_sha1_in_want variable with the flag-style allow_request_with_bare_object_name variable. Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-22Fourth batch for 2.5 cycleJunio C Hamano1-0/+75 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-22test_bitmap_walk: free bitmap with bitmap_freeJeff King1-1/+1 Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30) noticed that we leak the "result" bitmap. But we should use "bitmap_free" rather than straight "free", as the former remembers to free the bitmap array pointed to by the struct. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-22doc: fix inconsistent spelling of "packfile"Patrick Steinhardt2-3/+3 Fix remaining instances where "pack-file" is used instead of "packfile". Some places remain where we still use "pack-file", This is the case when we explicitly refer to a file with a ".pack" extension as opposed to a data source providing a pack data stream. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-22t5407: use <<- to align the expected outputJunio C Hamano1-40/+40 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-22rebase -i: fix post-rewrite hook with failed exec commandMatthieu Moy2-6/+6 Usually, when 'git rebase' stops before completing the rebase, it is to give the user an opportunity to edit a commit (e.g. with the 'edit' command). In such cases, 'git rebase' leaves the sha1 of the commit being rewritten in "$state_dir"/stopped-sha, and subsequent 'git rebase --continue' will call the post-rewrite hook with this sha1 as <old-sha1> argument to the post-rewrite hook. The case of 'git rebase' stopping because of a failed 'exec' command is different: it gives the opportunity to the user to examine or fix the failure, but does not stop saying "here's a commit to edit, use --continue when you're done". So, there's no reason to call the post-rewrite hook for 'exec' commands. If the user did rewrite the commit, it would be with 'git commit --amend' which already called the post-rewrite hook. Fix the behavior to leave no stopped-sha file in case of failed exec command, and teach 'git rebase --continue' to skip record_in_rewritten if no stopped-sha file is found. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-22rebase -i: demonstrate incorrect behavior of post-rewriteMatthieu Moy1-0/+17 The 'exec' command is sending the current commit to stopped-sha, which is supposed to contain the original commit (before rebase). As a result, if an 'exec' command fails, the next 'git rebase --continue' will send the current commit as <old-sha1> to the post-rewrite hook. The test currently fails with : --- expected.data 2015-05-21 17:55:29.000000000 +0000 +++ [...]post-rewrite.data 2015-05-21 17:55:29.000000000 +0000 @@ -1,2 +1,3 @@ 2362ae8e1b1b865e6161e6f0e165ffb974abf018 488028e9fac0b598b70cbeb594258a917e3f6fab +488028e9fac0b598b70cbeb594258a917e3f6fab 488028e9fac0b598b70cbeb594258a917e3f6fab babc8a4c7470895886fc129f1a015c486d05a351 8edffcc4e69a4e696a1d4bab047df450caf99507 Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-21config.txt: clarify allowTipSHA1InWant with camelCaseFredrik Medley1-2/+2 Most of the options in config.txt are camelCase. Improve the readability for allowtipsha1inwant by changing to allowTipSHA1InWant. Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-21help: respect new common command groupingSébastien Guimmara1-1/+23 'git help' shows common commands in alphabetical order: The most commonly used git commands are: add Add file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository [...] without any indication of how commands relate to high-level concepts or each other. Revise the output to explain their relationship with the typical Git workflow: These are common Git commands used in various situations: start a working area (see also: git help tutorial) clone Clone a repository into a new directory init Create an empty Git repository or reinitialize [...] work on the current change (see also: git help everyday) add Add file contents to the index reset Reset current HEAD to the specified state examine the history and state (see also: git help revisions) log Show commit logs status Show the working tree status [...] Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-21command-list.txt: drop the "common" tagSébastien Guimmara1-21/+21 command-list.sh, retired in the previous patch, was the only consumer of the "common" tag, so drop this now-unnecessary attribute. before: git-add mainporcelain common worktree after: git-add mainporcelain worktree Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-21generate-cmdlist: parse common group commandsEric Sunshine3-25/+52 Parse the group block to create the array of group descriptions: static char *common_cmd_groups[] = { N_("starting a working area"), N_("working on the current change"), N_("working with others"), N_("examining the history and state"), N_("growing, marking and tweaking your history"), }; then map each element of common_cmds[] to a group via its index: static struct cmdname_help common_cmds[] = { {"add", N_("Add file contents to the index"), 1}, {"branch", N_("List, create, or delete branches"), 4}, {"checkout", N_("Checkout a branch or paths to the ..."), 4}, {"clone", N_("Clone a repository into a new directory"), 0}, {"commit", N_("Record changes to the repository"), 4}, ... }; so that 'git help' can print those commands grouped by theme. Only commands tagged with an attribute from the group block are emitted to common_cmds[]. [commit message by Sébastien Guimmara <sebastien.guimmara@gmail.com>] Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-21command-list.txt: add the common groups blockSébastien Guimmara2-21/+33 The ultimate goal is for "git help" to display common commands in groups rather than alphabetically. As a first step, define the groups in a new block, and then assign a group to each common command. Add a block at the beginning of command-list.txt: init start a working area (see also: git help tutorial) worktree work on the current change (see also:[...] info examine the history and state (see also: git [...] history grow, mark and tweak your history remote collaborate (see also: git help workflows) storing information about common commands group, then map each common command to a group: git-add mainporcelain common worktree Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Emma Jane Hogbin Westby <emma.westby@gmail.com> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-21command-list: prepare machinery for upcoming "common groups" sectionEric Sunshine3-3/+8 The ultimate goal is for "git help" to classify common commands by group. Toward this end, a subsequent patch will add a new "common groups" section to command-list.txt preceding the actual command list. As preparation, teach existing command-list.txt parsing machinery, which doesn't care about grouping, to skip over this upcoming "common groups" section. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20Documentation/log: clarify sha1 non-abbreviation in log --rawMatthieu Moy1-1/+4 Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20dir: remove unused variable sbRené Scharfe1-2/+0 It had never been used. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20clean: remove unused variable bufRené Scharfe1-2/+0 It had never been used. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20use file_exists() to check if a file exists in the worktreeRené Scharfe5-22/+9 Call file_exists() instead of open-coding it. That's shorter, simpler and the intent becomes clearer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20stash: recognize "--help" for subcommandsJeff King1-0/+11 If you run "git stash --help", you get the help for stash (this magic is done by the git wrapper itself). But if you run "git stash drop --help", you get an error. We cannot show help specific to "stash drop", of course, but we can at least give the user the normal stash manpage. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20stash: complain about unknown flagsJeff King2-1/+9 The option parser for git-stash stuffs unknown flags into the $FLAGS variable, where they can be accessed by the individual commands. However, most commands do not even look at these extra flags, leading to unexpected results like this: $ git stash drop --help Dropped refs/stash@{0} (e6cf6d80faf92bb7828f7b60c47fc61c03bd30a1) We should notice the extra flags and bail. Rather than annotate each command to reject a non-empty $FLAGS variable, we can notice that "stash show" is the only command that actually _wants_ arbitrary flags. So we switch the default mode to reject unknown flags, and let stash_show() opt into the feature. Reported-by: Vincent Legoll <vincent.legoll@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20cat-file: add --follow-symlinks to --batchDavid Turner3-7/+348 This wires the in-repo-symlink following code through to the cat-file builtin. In the event of an out-of-repo link, cat-file will print the link in a new format. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20sha1_name: get_sha1_with_context learns to follow symlinksDavid Turner2-12/+28 Wire up get_sha1_with_context to call get_tree_entry_follow_symlinks when GET_SHA1_FOLLOW_SYMLINKS is passed in flags. G_S_FOLLOW_SYMLINKS is incompatible with G_S_ONLY_TO_DIE because the diagnosis that ONLY_TO_DIE triggers does not at present consider symlinks, and it would be a significant amount of additional code to allow it to do so. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-05-20tree-walk: learn get_tree_entry_follow_symlinksDavid Turner2-0/+224 Add a new function, get_tree_entry_follow_symlinks, to tree-walk.[ch]. The function is not yet used. It will be used to implement git cat-file --batch --follow-symlinks. The function locates an object by path, following symlinks in the repository. If the symlinks lead outside the repository, the function reports this to the caller. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>