1. 25 2月, 2014 4 次提交
  2. 15 2月, 2014 1 次提交
  3. 11 2月, 2014 7 次提交
  4. 08 2月, 2014 1 次提交
  5. 27 1月, 2014 2 次提交
    • R
      Fix lan9118 buffer length handling · c444dfab
      Roy Franz 提交于
      The 9118 ethernet controller supports transmission of multi-buffer packets
      with arbitrary byte alignment of the start and end bytes.  All writes to
      the packet fifo are 32 bits, so the controller discards bytes at the beginning
      and end of each buffer based on the 'Data start offset' and 'Buffer size'
      of the TX command 'A' format.
      
      This patch uses the provided buffer length to limit the bytes transmitted.
      Previously all the bytes of the last 32-bit word written to the TX fifo
      were added to the internal transmit buffer structure resulting in more bytes
      being transmitted than were submitted to the hardware in the command.  This
      resulted in extra bytes being inserted into the middle of multi-buffer
      packets when the non-final buffers had non-32bit aligned ending addresses.
      Signed-off-by: NRoy Franz <roy.franz@linaro.org>
      Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      c444dfab
    • R
      Fix lan9118 TX "CMD A" handling · 2ad657e3
      Roy Franz 提交于
      The 9118 ethernet controller supports transmission of multi-buffer packets
      with arbitrary byte alignment of the start and end bytes.  All writes to
      the packet fifo are 32 bits, so the controller discards bytes at the beginning
      and end of each buffer based on the 'Data start offset' and 'Buffer size'
      of the TX command 'A' format.
      
      This patch changes the buffer size and offset internal state variables to be
      updated on every "TX command A" write.  Previously they were only updated for
      the first segment, which resulted incorrect behavior for packets with more
      than one segment. Each segment of the packet has its own CMD A command, with
      its own buffer size and start offset.
      
      Also update extraction of fields from the CMD A word to use extract32().
      Signed-off-by: NRoy Franz <roy.franz@linaro.org>
      Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      2ad657e3
  6. 26 1月, 2014 1 次提交
  7. 07 1月, 2014 1 次提交
  8. 25 12月, 2013 1 次提交
    • M
      hw: cannot_instantiate_with_device_add_yet due to pointer props · 1b111dc1
      Markus Armbruster 提交于
      Pointer properties can be set only by code, not by device_add.  A
      device with a pointer property can work with device_add only when the
      property may remain null.
      
      This is the case for property "interrupt_vector" of device
      "etraxfs,pic".  Add a comment there.
      
      Set cannot_instantiate_with_device_add_yet for the other devices with
      pointer properties, with a comment explaining why.
      
      Juha Riihimäki and Peter Maydell deserve my thanks for making "pointer
      property must not remain null" blatantly obvious in the OMAP devices.
      
      Only device "smbus-eeprom" is actually changed.  The others are all
      sysbus devices, which get cannot_instantiate_with_device_add_yet set
      in their abstract base's class init function.  Setting it again in
      their class init function is technically redundant, but serves as
      insurance for when sysbus devices become available with device_add,
      and as documentation.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: Edgar E. Iglesias <edgar.iglesias@gmail.com> (for ETRAX)
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      1b111dc1
  9. 10 12月, 2013 18 次提交
  10. 09 12月, 2013 1 次提交
  11. 03 12月, 2013 1 次提交
  12. 21 11月, 2013 1 次提交
    • M
      Revert "e1000/rtl8139: update HMP NIC when every bit is written" · 90d131fb
      Michael S. Tsirkin 提交于
      This reverts commit cd5be582.
      Digging into hardware specs shows this does not
      actually make QEMU behave more like hardware:
      
      There are valid arguments backed by the spec to indicate why the version
      of e1000 prior to cd5be582 was more correct: the high byte actually
      includes a valid bit, this is why all guests write it last.
      
      For rtl8139 there's actually a separate undocumented valid bit, but we
      don't implement it yet.
      
      To summarize all the drivers we know about behave in one way
      that allows us to make an assumption about write order and avoid
      spurious, incorrect mac address updates to the monitor.
      
      Let's stick to the tried heuristic for 1.7 and
      possibly revisit for 1.8.
      Reported-by: NVlad Yasevich <vyasevic@redhat.com>
      Reviewed-by: NVlad Yasevich <vyasevic@redhat.com>
      Cc: Amos Kong <akong@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      90d131fb
  13. 19 11月, 2013 1 次提交
新手
引导
客服 返回
顶部