GitHub PushEvent at 2014-10-14 08:57:25
Repository: linux
Actor: Ekkehardt
Payload: {"shas":[["1d2ce978d160fa960f12d06bf84e45f47c141272","1416ae054606eb9be8fa0d7696a4ddff667a3601@hmh.eng.br","x86, microcode, amd: Fix missing static declaration\n\nMake locally used variable static.\n\nSigned-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>\nLink: http://lkml.kernel.org/r/1406146251-8540-1-git-send-email-hmh@hmh.eng.br\nSigned-off-by: Borislav Petkov <bp@suse.de>","Henrique de Moraes Holschuh",true],["05a5f76d033f413396bc48ce2f8651b5659bcd31","1416ae054606eb9be8fa0d7696a4ddff667a3601@hmh.eng.br","x86, microcode, intel: Add missing static declarations\n\ngcc reports that a few declarations are missing.\nFix two obvious ones.\n\nSigned-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>\nLink: http://lkml.kernel.org/r/1406146251-8540-1-git-send-email-hmh@hmh.eng.br\nSigned-off-by: Borislav Petkov <bp@suse.de>","Henrique de Moraes Holschuh",true],["f99b45c3c2aa6960b8d21bb200d144be48a0a783","1416ae054606eb9be8fa0d7696a4ddff667a3601@hmh.eng.br","x86, microcode, intel: Fix typos\n\nFix some typos. One of them was in a struct name, fortunately harmless\nbecause it happened on a \"sizeof(struct foo*)\" construction.\n\nSigned-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>\nLink: http://lkml.kernel.org/r/1406146251-8540-1-git-send-email-hmh@hmh.eng.br\nSigned-off-by: Borislav Petkov <bp@suse.de>","Henrique de Moraes Holschuh",true],["532ed3740c1ed1583ea3fa6de9410edf0d508563","1416ae054606eb9be8fa0d7696a4ddff667a3601@hmh.eng.br","x86, microcode, intel: Rename apply_microcode and declare it static\n\nRename apply_microcode() in microcode/intel.c to\napply_microcode_intel(), and declare it as static. This is a cosmetic\nfix to silence a warning issued by sparse.\n\nSigned-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>\nLink: http://lkml.kernel.org/r/1406146251-8540-1-git-send-email-hmh@hmh.eng.br\nSigned-off-by: Borislav Petkov <bp@suse.de>","Henrique de Moraes Holschuh",true],["ebc14ddcc9454c02439b67f6536628289faaa26e","1416ae054606eb9be8fa0d7696a4ddff667a3601@hmh.eng.br","x86, microcode, intel: Fix total_size computation\n\nAccording to the Intel SDM vol 3A (order code 253668-051US, June 2014),\non section 9.11.1, page 9-28:\n\n\"For microcode updates with a data size field equal to 00000000H, the\nsize of the microcode update is 2048 bytes. The first 48 bytes contain\nthe microcode update header. The remaining 2000 bytes contain encrypted\ndata.\"\n\n\"For microcode updates with a data size not equal to 00000000H, the total\nsize field specifies the size of the microcode update.\"\n\nUp to 2002/2003, Intel used an \"old format\" for the microcode update\ncontainers that was always 2048 bytes in size. That old format did not\nhave Data Size and Total Size fields, the quadwords at those positions\nin the microcode container header were \"reserved\". The microcode header\nof the \"old format\" microcode container has a hrdver of 0x01. You can\nhunt down an old copy of the Intel SDM to validate this through its\norder number (#243192). I found one from 1999 through a Google search.\n\nSometime in 2002/2003 (AFAICT, for the Prescott processors), Intel\ndocumented a new format for the microcode containers and contributed in\n2003 some code to the Linux kernel microcode driver implementing support\nfor the new format. This new format has Data Size and Total Size fields,\nas well as the optional extended signature table. However, it reuses the\nsame hrdver as the old format (0x01), and it can only be told apart from\nthe old format by a non-zero Data Size field.\n\nIn fact, the only reason we can even trust a Data Size of zero to mean\nthat the microcode container is in the old format, is because Intel\nreatroatively promised that the old format would always have a zero\nthere when they wrote the documentation for the _new_ format.\n\nThis is a very old bug, dating back to 2003. It has been dormant\never since, as Intel seems to set all reserved fields to zero on the\nmicrocode updates they distribute: I could not find a public microcode\nupdate that would trigger this bug.\n\nSigned-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>\nLink: http://lkml.kernel.org/r/1406146251-8540-1-git-send-email-hmh@hmh.eng.br\nSigned-off-by: Borislav Petkov <bp@suse.de>","Henrique de Moraes Holschuh",true],["83f45fc360c8e16a330474860ebda872d1384c8c","c1b6782c4af8f0673da8923a0702a1832e5940f4@ffwll.ch","drm: Don't grab an fb reference for the idr\n\nThe current refcounting scheme is that the fb lookup idr also holds a\nreference. This works out nicely bacause thus far we've always\nexplicitly cleaned up idr entries for framebuffers:\n- Userspace fbs get removed in the rmfb ioctl or when the drm file\n  gets closed.\n- Kernel fbs (for fbdev emulation) get cleaned up by the driver code\n  at module unload time.\n\nBut now i915 also reconstructs the bios fbs for a smooth transition.\nAnd that fb is purely transitional and should get removed immmediately\nonce all crtcs stop using it. Of course if the i915 fbdev code decides\nto reuse it as the main fbdev fb then it shouldn't be cleaned up, but\nin that case the fbdev code will grab it's own reference.\n\nThe problem is now that we also want to register that takeover fb in\nthe idr, so that userspace can do a smooth transition (animated maybe\neven!) itself. But currently we have no one who will clean up the idr\nreference once that fb isn't useful any more, and so essentially leak\nit.\n\nFix this by no longer holding a full fb reference for the idr, but\ninstead just have a weak reference using kref_get_unless_zero. But\nthat requires us to synchronize and clean up with the idr and fb_lock\nin drm_framebuffer_free, so add that. It's a bit ugly that we have to\nunconditionally grab the fb_lock, but without that someone might creep\nthrough a race.\n\nThis leak was caught by the fb leak check in drm_mode_config_cleanup.\nOriginally the leak was introduced in\n\ncommit 46f297fb83d4f9a6f6891964beb184664341a28b\nAuthor: Jesse Barnes <jbarnes@virtuousgeek.org>\nDate:   Fri Mar 7 08:57:48 2014 -0800\n\n    drm/i915: add plane_config fetching infrastructure v2\n\nCc:  Jesse Barnes <jbarnes@virtuousgeek.org>\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Daniel Vetter",true],["ea6763c104c93acb6554659fe4a3c9e9328a4b51","c1b6782c4af8f0673da8923a0702a1832e5940f4@ffwll.ch","video/fbdev: Always built-in video= cmdline parsing\n\nIn drm/i915 we want to get at the video= cmdline modes even when we\ndon't have fbdev support enabled, so that users can always override\nthe kernel's initial mode selection.\n\nBut that gives us a direct depency upon the parsing code in the fbdev\nsubsystem. Since it's so little code just extract these 2 functions\nand always build them in.\n\nWhiel at it fix the checkpatch fail in this code.\n\nv2: Also move fb_mode_option. Spotted by the kbuild.\n\nv3: Review from Geert:\n- Keep the old copyright notice from fb_mem.c, although I have no\nidea what exactly applies.\n- Only compile this when needed.\n\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nCc: Plagniol-Villard <plagnioj@jcrosoft.com>\nCc: Tomi Valkeinen <tomi.valkeinen@ti.com>\nCc: linux-fbdev@vger.kernel.org\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\n\n--\n\nI prefer if we can merge this through drm-next since we'll use it\nthere in follow-up patches.\n-Daniel","Daniel Vetter",true],["eaf99c749d43ae74ac7ffece5512f3c73f01dfd2","711c73f64afdce07b7e38039a96d2224209e9a6c@chris-wilson.co.uk","drm: Perform cmdline mode parsing during connector initialisation\n\ni915.ko has a custom fbdev initialisation routine that aims to preserve\nthe current mode set by the BIOS, unless overruled by the user. The\nuser's wishes are determined by what, if any, mode is specified on the\ncommand line (via the video= parameter). However, that command line mode\nis first parsed by drm_fb_helper_initial_config() which is called after\ni915.ko's custom initial_config() as a fallback method. So in order for\nus to honour it, we need to move the cmdline parser earlier. If we\nperform the connector cmdline parsing as soon as we initialise the\nconnector, that cmdline mode and forced status is then available even if\nthe fbdev helper is not compiled in or never called.\n\nWe also then expose the cmdline user mode in the connector mode lists.\n\nv2: Rebase after connector->name upheaval.\n\nv3: Adapt mga200 to look for the cmdline mode in the new place. Nicely\nsimplifies things while at that.\n\nv4: Fix checkpatch.\n\nv5: Select FB_CMDLINE to adapt to the changed fbdev patch.\n\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)\nCc: Jesse Barnes <jbarnes@virtuousgeek.org>\nCc: Ville Syrjälä <ville.syrjala@linux.intel.com>\nCc: Daniel Vetter <daniel.vetter@ffwll.ch>\nReviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)\nCc: dri-devel@lists.freedesktop.org\nCc: Julia Lemire <jlemire@matrox.com>\nCc: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Chris Wilson",true],["ddde43711fdde505ac413102faa2352704cd858a","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Warn when leaking flip events on close\n\nWarn when there are events on the file_priv->event_list just before\nfile_priv gets freed. This can occur if the driver doesn't clean up\npending page flip events in ->preclose().\n\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>","Ville Syrjälä",true],["e6ae8687a87b1fe5c25e824c8ad300f5587eb622","915c10c999604870200b6defbe633d857c856ca0@gmail.com","drm: idiot-proof vblank\n\nAfter spending slightly more time than I'd care to admit debugging the\nvarious and presumably spectacular way things fail when you pass too low\na value to drm_vblank_init() (thanks console-lock for not letting me see\nthe carnage!), I decided it might be a good idea to add some sanity\nchecking.\n\nSigned-off-by: Rob Clark <robdclark@gmail.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Rob Clark",true],["7ffd7a68511c710b84db3548a1997fd2625f580a","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Always reject drm_vblank_get() after drm_vblank_off()\n\nMake sure drm_vblank_get() never succeeds when called between\ndrm_vblank_off() and drm_vblank_on(). Borrow a trick from the\nold drm_vblank_{pre,post}_modeset() functions and just bump\nthe refcount in drm_vblank_off() and drop it in drm_vblank_on().\n\nWhen drm_vblank_get() encounters a >0 refcount and the vblank\ninterrupt is already disabled it will simply return -EINVAL.\n\nHopefully the use of inmodeset won't conflict badly with\ndrm_vblank_{pre,post}_modeset().\n\nFor i915 there's a window between drm_vblank_off() and marking the\ncrtc as inactive where the current code still allows drm_vblank_get().\n\nv2: Describe what drm_vblank_get() does to explain how\n    a simple refcount bump manages to fix things (Daniel)\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["08c71e5e817a956389af5da5e99ab3e26d5c673d","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off()\n\nv2: Drop the drm_vblank_off() (Daniel)\n    Use drm_crtc_vblank_{get,put}()\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["844b03f27739135fe1fed2fef06da0ffc4c7a081","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Don't clear vblank timestamps when vblank interrupt is disabled\n\nClearing the timestamps causes us to send zeroed timestamps to userspace\nif they get sent out in response to the drm_vblank_off(). It's better\nto send the very latest timestamp and count instead.\n\nTestcase: igt/kms_flip/modeset-vs-vblank-race\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["13b030af54a5e307cbcccdf5479873fbc4b7f185","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Move drm_update_vblank_count()\n\nMove drm_update_vblank_count() to avoid forward a declaration.\nNo functional change.\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["812e7465a7decf3cca0b5f71977a25eecd9626a4","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off()\n\nIf the vblank irq has already been disabled (via the disable timer) when\nwe call drm_vblank_off() sample the counter and timestamp one last time.\nThis will make the sure that the user space visible counter will account\nfor time between vblank irq disable and drm_vblank_off().\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["f8ad028cc033f75fc479ca1c30e2ea4ba56e5269","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Avoid random vblank counter jumps if the hardware counter has been reset\n\nWhen drm_vblank_on() is called the hardware vblank counter may have\nbeen reset, so we can't trust that the old values sampled prior to\ndrm_vblank_off() have anything to do with the new values.\n\nSo update the .last count in drm_vblank_on() to make the first\ndrm_vblank_enable() consider that as the reference point. This\nwill correct the user space visible counter to account for the\ntime between drm_vblank_on() and the first drm_vblank_enable()\ncalls.\n\nFor extra safety subtract one from the .last count in drm_vblank_on()\nto make sure that user space will never see the same counter value\nbefore and after modeset.\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["8a51d5bef07f1c8c59de20089fb27ea39d395f1b","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Reduce the amount of dev->vblank[crtc] in the code\n\nDeclare a local struct drm_vblank_crtc * and use that\ninstead of having to do dig it out via 'dev->vblank[crtc]'\neverywhere.\n\nPerformed with the following coccinelle incantation,\nand a few manual whitespace cleanups:\n\n@@\nidentifier func,member;\nexpression num_crtcs;\nstruct drm_device *dev;\nunsigned int crtc;\n@@\nfunc (...) {\n+ struct drm_vblank_crtc *vblank;\n...\nif (crtc >= num_crtcs)\n   return ...;\n+ vblank = &dev->vblank[crtc];\n<+...\n(\n- dev->vblank[crtc].member\n+ vblank->member\n|\n- &(dev->vblank[crtc])\n+ vblank\n)\n...+>\n}\n\n@@\nstruct drm_device *dev;\nint crtc;\nidentifier member;\nexpression num_crtcs;\n@@\nfor (crtc = 0; crtc < num_crtcs; crtc++) {\n+ struct drm_vblank_crtc *vblank = &dev->vblank[crtc];\n+\n<+...\n(\n- dev->vblank[crtc].member\n+ vblank->member\n|\n- &(dev->vblank[crtc])\n+ vblank\n)\n...+>\n}\n\n@@\nidentifier func,member;\n@@\nfunc (struct drm_device *dev, int crtc, ...) {\n+ struct drm_vblank_crtc *vblank = &dev->vblank[crtc];\n<+...\n(\n- dev->vblank[crtc].member\n+ vblank->member\n|\n- &(dev->vblank[crtc])\n+ vblank\n)\n...+>\n}\n\nv2: Rebased\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["56cc279b29c7b204fe7d0943509ae209b8b128db","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Fix deadlock between event_lock and vbl_lock/vblank_time_lock\n\nCurrently both drm_irq.c and several drivers call drm_vblank_put()\nwhile holding event_lock. Now that drm_vblank_put() can disable the\nvblank interrupt directly it may need to grab vbl_lock and\nvblank_time_lock. That causes deadlocks since we take the locks\nin the opposite order in two places in drm_irq.c. So let's make\nsure the locking order is always event_lock->vbl_lock->vblank_time_lock.\n\nIn drm_vblank_off() pull up event_lock from underneath vbl_lock. Hold\nthe event_lock across the whole operation to make sure we only send\nout the events that were on the queue when we disabled the interrupt,\nand not ones that got added just after (assuming drm_vblank_on() already\nmanaged to get called somewhere between).\n\nTo sort the other deadlock pull the event_lock out from\ndrm_handle_vblank_events() into drm_handle_vblank() to be taken outside\nvblank_time_lock. Add the appropriate assert_spin_locked() to\ndrm_handle_vblank_events().\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["ffe7c73a8d4f0caeebd5d220ddbf7126a4daca1f","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()\n\nCurrently it's possible that the following will happen:\n1. drm_wait_vblank() calls drm_vblank_get()\n2. drm_vblank_off() gets called\n3. drm_wait_vblank() calls drm_queue_vblank_event() which\n   adds the event to the queue event though vblank interrupts\n   are currently disabled (and may not be re-enabled ever again).\n\nTo fix the problem, add another vblank->enabled check into\ndrm_queue_vblank_event().\n\ndrm_vblank_off() holds event_lock around the vblank disable,\nso no further locking needs to be added to drm_queue_vblank_event().\nvblank disable from another source is not possible since\ndrm_wait_vblank() already holds a vblank reference.\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true],["4ed0ce3d0bccd74416ba6beb33a8a79d1617e97b","cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","drm: Disable vblank interrupt immediately when drm_vblank_offdelay<0\n\nMake drm_vblank_put() disable the vblank interrupt immediately when the\nrefcount drops to zero and drm_vblank_offdelay<0.\n\nv2: Preserve the current drm_vblank_offdelay==0 'never disable' behaviur\n\nReviewed-by: Matt Roper <matthew.d.roper@intel.com>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Ville Syrjälä",true]],"size":976,"ref":"refs/heads/master","head":"2d65a9f48fcdf7866aab6457bc707ca233e0c791"}