From: Prasad J Pandit <pjp@fedoraproject.org>

In SDHCI protocol, the transfer mode register is defined
to be of 6 bits. Mask its value with '0x0037' so that an
invalid value could not be assigned.

Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
---
 hw/sd/sdhci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Update per: use macro for the mask value
  -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02774.html

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 5bd5ab6..cf647fa 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -119,6 +119,7 @@
     (SDHC_CAPAB_BASECLKFREQ << 8) | (SDHC_CAPAB_TOUNIT << 7) | \
     (SDHC_CAPAB_TOCLKFREQ))
 
+#define MASK_TRNMOD     0x0037
 #define MASKED_WRITE(reg, mask, val)  (reg = (reg & (mask)) | (val))
 
 static uint8_t sdhci_slotint(SDHCIState *s)
@@ -1050,7 +1051,7 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, unsigned size)
         if (!(s->capareg & SDHC_CAN_DO_DMA)) {
             value &= ~SDHC_TRNS_DMA;
         }
-        MASKED_WRITE(s->trnmod, mask, value);
+        MASKED_WRITE(s->trnmod, mask, value & MASK_TRNMOD);
         MASKED_WRITE(s->cmdreg, mask >> 16, value >> 16);
 
         /* Writing to the upper byte of CMDREG triggers SD command generation */
-- 
2.9.3

On 14 February 2017 at 06:22, P J P <ppandit@redhat.com> wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
> In SDHCI protocol, the transfer mode register is defined
> to be of 6 bits. Mask its value with '0x0037' so that an
> invalid value could not be assigned.
>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>

What has happened to the other patches that were in this
patchset in v3 ?

thanks
-- PMM

+-- On Tue, 14 Feb 2017, Peter Maydell wrote --+
| What has happened to the other patches that were in this patchset in v3 ?

v3 1/4
  -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02776.html

v3 3/4
  -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02775.html

These two are acked.


v3 2/4
  -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02846.html
  -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02844.html

v3 4/4
  -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02380.html
  -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01568.html

These two were acked with few changes, which are incorporated in the second 
link above. Acks pending.

Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

On 14 February 2017 at 10:44, P J P <ppandit@redhat.com> wrote:
> +-- On Tue, 14 Feb 2017, Peter Maydell wrote --+
> | What has happened to the other patches that were in this patchset in v3 ?
>
> v3 1/4
>   -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02776.html
>
> v3 3/4
>   -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02775.html
>
> These two are acked.
>
>
> v3 2/4
>   -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02846.html
>   -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02844.html
>
> v3 4/4
>   -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02380.html
>   -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01568.html
>
> These two were acked with few changes, which are incorporated in the second
> link above. Acks pending.

Please keep sending them as a single series, though. Otherwise I
won't be able to easily apply them in the right order and track
their current status.

thanks
-- PMM

  Hello Peter,

+-- On Tue, 14 Feb 2017, Peter Maydell wrote --+
| Please keep sending them as a single series, though. Otherwise I
| won't be able to easily apply them in the right order and track
| their current status.

  Okay, got it. Ie. to re-send entire series even for change in one of the 
patches?

Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

On 14 February 2017 at 11:02, P J P <ppandit@redhat.com> wrote:
>   Hello Peter,
>
> +-- On Tue, 14 Feb 2017, Peter Maydell wrote --+
> | Please keep sending them as a single series, though. Otherwise I
> | won't be able to easily apply them in the right order and track
> | their current status.
>
>   Okay, got it. Ie. to re-send entire series even for change in one of the
> patches?

Yes, exactly. (We document this in
http://wiki.qemu-project.org/Contribute/SubmitAPatch#Participating_in_Code_Review
but of course that page is huge...)

thanks
-- PMM

  Hello Petr,

+-- On Tue, 14 Feb 2017, Peter Maydell wrote --+
| Yes, exactly. (We document this in 
| http://wiki.qemu-project.org/Contribute/SubmitAPatch#Participating_in_Code_Review 
| but of course that page is huge...)

  Right, okay. I'll resend the patch set later today.

Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F