1. 19 12月, 2013 1 次提交
  2. 18 12月, 2013 2 次提交
    • T
      drm: Add panel support · aead40ea
      Thierry Reding 提交于
      Add a very simple framework to register and lookup panels. Panel drivers
      can initialize a DRM panel and register it with the framework, allowing
      them to be retrieved and used by display drivers. Currently only support
      for DPMS and obtaining panel modes is provided. However it should be
      sufficient to enable a large number of panels. The framework should also
      be easily extensible to support more sophisticated kinds of panels such
      as DSI.
      
      The framework hasn't been tied into the DRM core, even though it should
      be easily possible to do so if that's what we want. In the current
      implementation, display drivers can simple make use of it to retrieve a
      panel, obtain its modes and control its DPMS mode.
      
      Note that this is currently only tested on systems that boot from a
      device tree. No glue code has been written yet for systems that use
      platform data, but it should be easy to add.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      aead40ea
    • A
      drm: Add MIPI DSI bus support · 068a0023
      Andrzej Hajda 提交于
      MIPI DSI bus allows to model DSI hosts and DSI peripherals using the
      Linux driver model. DSI hosts are registered by the DSI host drivers.
      During registration DSI peripherals will be created from the children
      of the DSI host's device tree node. Support for registration from
      board-setup code will be added later when needed.
      
      DSI hosts expose operations which can be used by DSI peripheral drivers
      to access associated devices.
      Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      068a0023
  3. 17 12月, 2013 2 次提交
  4. 13 12月, 2013 6 次提交
  5. 12 12月, 2013 4 次提交
  6. 11 12月, 2013 3 次提交
  7. 10 12月, 2013 6 次提交
    • T
      ALSA: compress: Fix 64bit ABI incompatibility · 6733cf57
      Takashi Iwai 提交于
      snd_pcm_uframes_t is defined as unsigned long so it would take
      different sizes depending on 32 or 64bit architectures.  As we don't
      want this ABI incompatibility, and there is no real 64bit user yet,
      let's make it the fixed size with __u32.
      
      Also bump the protocol version number to 0.1.2.
      Acked-by: NVinod Koul <vinod.koul@intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6733cf57
    • S
      ALSA: memalloc.h - fix wrong truncation of dma_addr_t · 932e9dec
      Stefano Panella 提交于
      When running a 32bit kernel the hda_intel driver is still reporting
      a 64bit dma_mask if the HW supports it.
      
      From sound/pci/hda/hda_intel.c:
      
              /* allow 64bit DMA address if supported by H/W */
              if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
                      pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
              else {
                      pci_set_dma_mask(pci, DMA_BIT_MASK(32));
                      pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
              }
      
      which means when there is a call to dma_alloc_coherent from
      snd_malloc_dev_pages a machine address bigger than 32bit can be returned.
      This can be true in particular if running  the 32bit kernel as a pv dom0
      under the Xen Hypervisor or PAE on bare metal.
      
      The problem is that when calling setup_bdle to program the BLE the
      dma_addr_t returned from the dma_alloc_coherent is wrongly truncated
      from snd_sgbuf_get_addr if running a 32bit kernel:
      
      static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab,
                                                 size_t offset)
      {
              struct snd_sg_buf *sgbuf = dmab->private_data;
              dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
              addr &= PAGE_MASK;
              return addr + offset % PAGE_SIZE;
      }
      
      where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr.
      
      Without this patch the HW will fetch the 32bit truncated address,
      which is not the one obtained from dma_alloc_coherent and will result
      to a non working audio but can corrupt host memory at a random location.
      
      The current patch apply to v3.13-rc3-74-g6c843f5
      Signed-off-by: NStefano Panella <stefano.panella@citrix.com>
      Reviewed-by: NFrediano Ziglio <frediano.ziglio@citrix.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      932e9dec
    • S
      dma: add dma_get_any_slave_channel(), for use in of_xlate() · 8010dad5
      Stephen Warren 提交于
      mmp_pdma.c implements a custom of_xlate() function that is 95% identical
      to what Tegra will need. Create a function to implement the common part,
      so everyone doesn't just cut/paste the implementation.
      
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: dmaengine@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      8010dad5
    • S
      dma: add channel request API that supports deferred probe · 0ad7c000
      Stephen Warren 提交于
      dma_request_slave_channel() simply returns NULL whenever DMA channel
      lookup fails. Lookup could fail for two distinct reasons:
      
      a) No DMA specification exists for the channel name.
         This includes situations where no DMA specifications exist at all, or
         other general lookup problems.
      
      b) A DMA specification does exist, yet the driver for that channel is not
         yet registered.
      
      Case (b) should trigger deferred probe in client drivers. However, since
      they have no way to differentiate the two situations, it cannot.
      
      Implement new function dma_request_slave_channel_reason(), which performs
      identically to dma_request_slave_channel(), except that it returns an
      error-pointer rather than NULL, which allows callers to detect when
      deferred probe should occur.
      
      Eventually, all drivers should be converted to this new API, the old API
      removed, and the new API renamed to the more desirable name. This patch
      doesn't convert the existing API and all drivers in one go, since some
      drivers call dma_request_slave_channel() then dma_request_channel() if
      that fails. That would require either modifying dma_request_channel() in
      the same way, or adding extra error-handling code to all affected
      drivers, and there are close to 100 drivers using the other API, rather
      than just the 15-20 or so that use dma_request_slave_channel(), which
      might be tenable in a single patch.
      
      acpi_dma_request_slave_chan_by_name() doesn't currently implement
      deferred probe. It should, but this will be addressed later.
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      0ad7c000
    • S
      ASoC: dmaengine: add custom DMA config to snd_dmaengine_pcm_config · 194c7dea
      Stephen Warren 提交于
      Add fields to struct snd_dmaengine_pcm_config to allow custom:
      
      - DMA channel names.
      
        This is useful when the default "tx" and "rx" channel names don't
        apply, for example if a HW module supports multiple channels, each
        having different DMA channel names. This is the case with the FIFOs
        in Tegra's AHUB. This new facility can replace
        SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME.
      
      - DMA device
      
        This allows requesting DMA channels for a device other than the device
        which is registering the "PCM" driver. This is quite unusual, but is
        currently useful on Tegra. In much HW, and in Tegra20, each DAI HW
        module contains its own FIFOs which DMA writes to. However, in Tegra30,
        the DMA FIFOs were split out AHUB HW module, which then routes the data
        through a cross-bar, and into the DAI HW modules. However, the current
        ASoC driver structure does not expose this detail, and acts as if the
        FIFOs are still part of the DAI HW modules. Consequently, the "PCM"
        driver is registered with the DAI HW module, yet the DMA channels must
        be looked up in the AHUB HW module's device tree node. This new config
        field allows that to happen. Eventually, the Tegra drivers will be
        reworked to fully expose the AHUB, and this config field can be
        removed.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      194c7dea
    • P
      [media] videobuf2: Add support for file access mode flags for DMABUF exporting · c1b96a23
      Philipp Zabel 提交于
      Currently it is not possible for userspace to map a DMABUF exported buffer
      with write permissions. This patch allows to also pass O_RDONLY/O_RDWR when
      exporting the buffer, so that userspace may map it with write permissions.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      c1b96a23
  8. 09 12月, 2013 1 次提交
  9. 08 12月, 2013 2 次提交
  10. 06 12月, 2013 3 次提交
  11. 03 12月, 2013 8 次提交
  12. 02 12月, 2013 2 次提交
    • E
      security: shmem: implement kernel private shmem inodes · c7277090
      Eric Paris 提交于
      We have a problem where the big_key key storage implementation uses a
      shmem backed inode to hold the key contents.  Because of this detail of
      implementation LSM checks are being done between processes trying to
      read the keys and the tmpfs backed inode.  The LSM checks are already
      being handled on the key interface level and should not be enforced at
      the inode level (since the inode is an implementation detail, not a
      part of the security model)
      
      This patch implements a new function shmem_kernel_file_setup() which
      returns the equivalent to shmem_file_setup() only the underlying inode
      has S_PRIVATE set.  This means that all LSM checks for the inode in
      question are skipped.  It should only be used for kernel internal
      operations where the inode is not exposed to userspace without proper
      LSM checking.  It is possible that some other users of
      shmem_file_setup() should use the new interface, but this has not been
      explored.
      
      Reproducing this bug is a little bit difficult.  The steps I used on
      Fedora are:
      
       (1) Turn off selinux enforcing:
      
      	setenforce 0
      
       (2) Create a huge key
      
      	k=`dd if=/dev/zero bs=8192 count=1 | keyctl padd big_key test-key @s`
      
       (3) Access the key in another context:
      
      	runcon system_u:system_r:httpd_t:s0-s0:c0.c1023 keyctl print $k >/dev/null
      
       (4) Examine the audit logs:
      
      	ausearch -m AVC -i --subject httpd_t | audit2allow
      
      If the last command's output includes a line that looks like:
      
      	allow httpd_t user_tmpfs_t:file { open read };
      
      There was an inode check between httpd and the tmpfs filesystem.  With
      this patch no such denial will be seen.  (NOTE! you should clear your
      audit log if you have tested for this previously)
      
      (Please return you box to enforcing)
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Hugh Dickins <hughd@google.com>
      cc: linux-mm@kvack.org
      c7277090
    • D
      KEYS: Fix multiple key add into associative array · 23fd78d7
      David Howells 提交于
      If sufficient keys (or keyrings) are added into a keyring such that a node in
      the associative array's tree overflows (each node has a capacity N, currently
      16) and such that all N+1 keys have the same index key segment for that level
      of the tree (the level'th nibble of the index key), then assoc_array_insert()
      calls ops->diff_objects() to indicate at which bit position the two index keys
      vary.
      
      However, __key_link_begin() passes a NULL object to assoc_array_insert() with
      the intention of supplying the correct pointer later before we commit the
      change.  This means that keyring_diff_objects() is given a NULL pointer as one
      of its arguments which it does not expect.  This results in an oops like the
      attached.
      
      With the previous patch to fix the keyring hash function, this can be forced
      much more easily by creating a keyring and only adding keyrings to it.  Add any
      other sort of key and a different insertion path is taken - all 16+1 objects
      must want to cluster in the same node slot.
      
      This can be tested by:
      
      	r=`keyctl newring sandbox @s`
      	for ((i=0; i<=16; i++)); do keyctl newring ring$i $r; done
      
      This should work fine, but oopses when the 17th keyring is added.
      
      Since ops->diff_objects() is always called with the first pointer pointing to
      the object to be inserted (ie. the NULL pointer), we can fix the problem by
      changing the to-be-inserted object pointer to point to the index key passed
      into assoc_array_insert() instead.
      
      Whilst we're at it, we also switch the arguments so that they are the same as
      for ->compare_object().
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
      IP: [<ffffffff81191ee4>] hash_key_type_and_desc+0x18/0xb0
      ...
      RIP: 0010:[<ffffffff81191ee4>] hash_key_type_and_desc+0x18/0xb0
      ...
      Call Trace:
       [<ffffffff81191f9d>] keyring_diff_objects+0x21/0xd2
       [<ffffffff811f09ef>] assoc_array_insert+0x3b6/0x908
       [<ffffffff811929a7>] __key_link_begin+0x78/0xe5
       [<ffffffff81191a2e>] key_create_or_update+0x17d/0x36a
       [<ffffffff81192e0a>] SyS_add_key+0x123/0x183
       [<ffffffff81400ddb>] tracesys+0xdd/0xe2
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NStephen Gallagher <sgallagh@redhat.com>
      23fd78d7