From mboxrd@z Thu Jan 1 00:00:00 1970 From: "C, Ramalingam" Subject: Re: [PATCH v9 08/39] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking Date: Thu, 20 Dec 2018 16:59:13 +0530 Message-ID: References: <1544673701-6353-1-git-send-email-ramalingam.c@intel.com> <1544673701-6353-9-git-send-email-ramalingam.c@intel.com> <20181219154800.GP21184@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1847221184==" Return-path: In-Reply-To: <20181219154800.GP21184@phenom.ffwll.local> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, seanpaul@chromium.org, tomas.winkler@intel.com List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --===============1847221184== Content-Type: multipart/alternative; boundary="------------6FCFCFED2CFD10DF532848D7" Content-Language: en-US This is a multi-part message in MIME format. --------------6FCFCFED2CFD10DF532848D7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/19/2018 9:18 PM, Daniel Vetter wrote: > On Thu, Dec 13, 2018 at 09:31:10AM +0530, Ramalingam C wrote: >> "hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status. >> This SW tracking is used to determine the need for real hdcp1.4 disable >> and hdcp_check_link upon CP_IRQ. >> >> On CP_IRQ we filter the CP_IRQ related to the states like Link failure >> and reauthentication req etc and handle them in hdcp_check_link. >> CP_IRQ corresponding to the authentication msg availability are ignored. >> >> WARN_ON is added for the abrupt stop of HDCP encryption of a port. >> >> Signed-off-by: Ramalingam C >> --- >> drivers/gpu/drm/i915/intel_dp.c | 2 +- >> drivers/gpu/drm/i915/intel_drv.h | 5 ++- >> drivers/gpu/drm/i915/intel_hdcp.c | 89 ++++++++++++++++++++++++++++++--------- >> 3 files changed, 74 insertions(+), 22 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c >> index aba884c64879..89315e15fb34 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -4758,7 +4758,7 @@ static void intel_dp_check_service_irq(struct intel_dp *intel_dp) >> intel_dp_handle_test_request(intel_dp); >> >> if (val & DP_CP_IRQ) >> - intel_hdcp_check_link(intel_dp->attached_connector); >> + intel_hdcp_handle_cp_irq(intel_dp->attached_connector); >> >> if (val & DP_SINK_SPECIFIC_IRQ) >> DRM_DEBUG_DRIVER("Sink specific irq unhandled\n"); >> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h >> index 191b6e0f086c..decd0346c6a7 100644 >> --- a/drivers/gpu/drm/i915/intel_drv.h >> +++ b/drivers/gpu/drm/i915/intel_drv.h >> @@ -393,6 +393,9 @@ struct intel_hdcp { >> struct delayed_work check_work; >> struct work_struct prop_work; >> >> + /* HDCP1.4 Encryption status */ >> + u8 hdcp_encrypted; > Another bool I guess? Or unsigned : 1; as per #intel-gfx discussion I will fallback to bool. > >> + >> /* HDCP2.2 related definitions */ >> /* Flag indicates whether this connector supports HDCP2.2 or not. */ >> u8 hdcp2_supported; >> @@ -2058,10 +2061,10 @@ int intel_hdcp_init(struct intel_connector *connector, >> bool hdcp2_supported); >> int intel_hdcp_enable(struct intel_connector *connector); >> int intel_hdcp_disable(struct intel_connector *connector); >> -int intel_hdcp_check_link(struct intel_connector *connector); >> bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port); >> bool intel_hdcp_capable(struct intel_connector *connector); >> bool is_hdcp2_supported(struct drm_i915_private *dev_priv); >> +void intel_hdcp_handle_cp_irq(struct intel_connector *connector); >> >> /* intel_psr.c */ >> #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support) >> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c >> index 9405fce07b93..2b7814a6f12b 100644 >> --- a/drivers/gpu/drm/i915/intel_hdcp.c >> +++ b/drivers/gpu/drm/i915/intel_hdcp.c >> @@ -75,6 +75,16 @@ bool intel_hdcp_capable(struct intel_connector *connector) >> return capable; >> } >> >> +static inline bool intel_hdcp_in_use(struct intel_connector *connector) >> +{ >> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev); >> + enum port port = connector->encoder->port; >> + u32 reg; >> + >> + reg = I915_READ(PORT_HDCP_STATUS(port)); >> + return reg & HDCP_STATUS_ENC; >> +} >> + >> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port, >> const struct intel_hdcp_shim *shim) >> { >> @@ -669,6 +679,7 @@ static int _intel_hdcp_disable(struct intel_connector *connector) >> DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n", >> connector->base.name, connector->base.base.id); >> >> + hdcp->hdcp_encrypted = 0; >> I915_WRITE(PORT_HDCP_CONF(port), 0); >> if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0, >> ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) { >> @@ -714,8 +725,10 @@ static int _intel_hdcp_enable(struct intel_connector *connector) >> /* Incase of authentication failures, HDCP spec expects reauth. */ >> for (i = 0; i < tries; i++) { >> ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim); >> - if (!ret) >> + if (!ret) { >> + hdcp->hdcp_encrypted = 1; >> return 0; >> + } >> >> DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret); >> >> @@ -742,16 +755,17 @@ int intel_hdcp_check_link(struct intel_connector *connector) >> enum port port = intel_dig_port->base.port; >> int ret = 0; >> >> - if (!hdcp->shim) >> - return -ENOENT; >> - >> mutex_lock(&hdcp->mutex); >> >> - if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED) >> + /* Check_link valid only when HDCP1.4 is enabled */ >> + if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED || >> + !hdcp->hdcp_encrypted) { >> + ret = -EINVAL; >> goto out; >> + } >> >> - if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) { >> - DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n", >> + if (WARN_ON(!intel_hdcp_in_use(connector))) { >> + DRM_ERROR("%s:%d HDCP link stopped encryption,%x\n", >> connector->base.name, connector->base.base.id, >> I915_READ(PORT_HDCP_STATUS(port))); >> ret = -ENXIO; >> @@ -792,18 +806,6 @@ int intel_hdcp_check_link(struct intel_connector *connector) >> return ret; >> } >> >> -static void intel_hdcp_check_work(struct work_struct *work) >> -{ >> - struct intel_hdcp *hdcp = container_of(to_delayed_work(work), >> - struct intel_hdcp, >> - check_work); >> - struct intel_connector *connector = intel_hdcp_to_connector(hdcp); >> - >> - if (!intel_hdcp_check_link(connector)) >> - schedule_delayed_work(&hdcp->check_work, >> - DRM_HDCP_CHECK_PERIOD_MS); >> -} > Why move the function? This will be used as common work fn for both 1.4 and 2.2. hdcp2_check_link will be defined below. So moving this to the group of common functions. Basically to avoid the function declarations. >> - >> static void intel_hdcp_prop_work(struct work_struct *work) >> { >> struct intel_hdcp *hdcp = container_of(work, struct intel_hdcp, >> @@ -1028,6 +1030,25 @@ int hdcp2_deauthenticate_port(struct intel_connector *connector) >> return hdcp2_close_mei_session(connector); >> } >> >> +static inline void _intel_hdcp_check_work(struct intel_connector *connector) >> +{ >> + struct intel_hdcp *hdcp = &connector->hdcp; >> + >> + if (!intel_hdcp_check_link(connector)) >> + schedule_delayed_work(&hdcp->check_work, >> + DRM_HDCP_CHECK_PERIOD_MS); >> +} >> + >> +static void intel_hdcp_check_work(struct work_struct *work) >> +{ >> + struct intel_hdcp *hdcp = container_of(to_delayed_work(work), >> + struct intel_hdcp, >> + check_work); >> + struct intel_connector *connector = intel_hdcp_to_connector(hdcp); >> + >> + _intel_hdcp_check_work(connector); >> +} >> + >> static int i915_hdcp_component_match(struct device *dev, void *data) >> { >> return !strcmp(dev->driver->name, "mei_hdcp"); >> @@ -1156,7 +1177,8 @@ int intel_hdcp_disable(struct intel_connector *connector) >> >> if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) { >> hdcp->value = DRM_MODE_CONTENT_PROTECTION_UNDESIRED; >> - ret = _intel_hdcp_disable(connector); >> + if (hdcp->hdcp_encrypted) >> + ret = _intel_hdcp_disable(connector); >> } >> >> mutex_unlock(&hdcp->mutex); >> @@ -1196,3 +1218,30 @@ void intel_hdcp_atomic_check(struct drm_connector *connector, >> new_state->crtc); >> crtc_state->mode_changed = true; >> } >> + >> +/* Handles the CP_IRQ raised from the DP HDCP sink */ >> +void intel_hdcp_handle_cp_irq(struct intel_connector *connector) >> +{ >> + struct intel_hdcp *hdcp = &connector->hdcp; >> + >> + if (!hdcp->shim) >> + return; >> + >> + /* >> + * As of now we want to handle CP_IRQ triggered while encryption is >> + * enabled. This includes the notification for Topology change, >> + * Link failure, reauth request etc. >> + * Auth msg availability notifications are ignored with mutex_trylock >> + * as authentication holds the lock. Lock might be taken for link check >> + * or hdcp_disable too. In either of state we need not handle the >> + * CP_IRQ, for known reasons. >> + */ >> + if (!mutex_trylock(&hdcp->mutex)) > This is not a good way to fix recursions, because the lock might be held > by someone else for other reasons, and then you just drop events on the > floor. Worse, usually it works, except when it stops working. This is attempt to drop the CP_IRQ received during mutex is locked. Because of the below reasoning: This mutex is taken by authentication enable/disable and check_link worker when enable is in process this CP_IRQ will be notifying the msg availability to read. at present we dont use the CP_IRQ for msg read. when disable is in process it doesn't matter why this CP_IRQ is triggered, we just want to ignore. When check_link is in progress, that means hdcp is enabled. So this CP_IRQ is for topology change/reauth request etc, which are handled by check_link. so once again we dont care for this CP_IRQs too. So basically if the mutex is already taken we can ignore/drop the CP_IRQ. So mutex_trylock helps us to do this. May be I should add all of these in the comment!? While rethinking on that we can reschedule the check_link work on every CP_IRQ. As this is harmless i will do that. Makes things simple. > > Since you already have a separate worker just schedule that one, and leave > it up to the worker to filter out events we don't care about. >> + return; >> + >> + if (!hdcp->hdcp_encrypted) >> + return; > This check would need to be moved intel_hdcp_check_link(). Function has the check already. I can avoid the check here and directly land into check_link work fn. -Ram >> + >> + mutex_unlock(&hdcp->mutex); >> + _intel_hdcp_check_work(connector); > So instead of the direct call we need a schedule_work() here (without > delay ofc). Note that if the work is already scheduled it won't be > scheduled to run twice, so should just work as-is I think. > -Daniel >> +} >> -- >> 2.7.4 >> --------------6FCFCFED2CFD10DF532848D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 12/19/2018 9:18 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:10AM +0530, Ramalingam C wrote:

"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.

On CP_IRQ we filter the CP_IRQ related to the states like Link failure
and reauthentication req etc and handle them in hdcp_check_link.
CP_IRQ corresponding to the authentication msg availability are ignored.

WARN_ON is added for the abrupt stop of HDCP encryption of a port.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  5 ++-
 drivers/gpu/drm/i915/intel_hdcp.c | 89 ++++++++++++++++++++++++++++++---------
 3 files changed, 74 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aba884c64879..89315e15fb34 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4758,7 +4758,7 @@ static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
 		intel_dp_handle_test_request(intel_dp);
 
 	if (val & DP_CP_IRQ)
-		intel_hdcp_check_link(intel_dp->attached_connector);
+		intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
 
 	if (val & DP_SINK_SPECIFIC_IRQ)
 		DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 191b6e0f086c..decd0346c6a7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -393,6 +393,9 @@ struct intel_hdcp {
 	struct delayed_work check_work;
 	struct work_struct prop_work;
 
+	/* HDCP1.4 Encryption status */
+	u8 hdcp_encrypted;

Another bool I guess? Or unsigned : 1;
as per #intel-gfx discussion I will fallback to bool.


+
 	/* HDCP2.2 related definitions */
 	/* Flag indicates whether this connector supports HDCP2.2 or not. */
 	u8 hdcp2_supported;
@@ -2058,10 +2061,10 @@ int intel_hdcp_init(struct intel_connector *connector,
 		    bool hdcp2_supported);
 int intel_hdcp_enable(struct intel_connector *connector);
 int intel_hdcp_disable(struct intel_connector *connector);
-int intel_hdcp_check_link(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 bool intel_hdcp_capable(struct intel_connector *connector);
 bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
 
 /* intel_psr.c */
 #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
index 9405fce07b93..2b7814a6f12b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -75,6 +75,16 @@ bool intel_hdcp_capable(struct intel_connector *connector)
 	return capable;
 }
 
+static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+{
+	struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+	enum port port = connector->encoder->port;
+	u32 reg;
+
+	reg = I915_READ(PORT_HDCP_STATUS(port));
+	return reg & HDCP_STATUS_ENC;
+}
+
 static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
 				    const struct intel_hdcp_shim *shim)
 {
@@ -669,6 +679,7 @@ static int _intel_hdcp_disable(struct intel_connector *connector)
 	DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
 		      connector->base.name, connector->base.base.id);
 
+	hdcp->hdcp_encrypted = 0;
 	I915_WRITE(PORT_HDCP_CONF(port), 0);
 	if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
 				    ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
@@ -714,8 +725,10 @@ static int _intel_hdcp_enable(struct intel_connector *connector)
 	/* Incase of authentication failures, HDCP spec expects reauth. */
 	for (i = 0; i < tries; i++) {
 		ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
-		if (!ret)
+		if (!ret) {
+			hdcp->hdcp_encrypted = 1;
 			return 0;
+		}
 
 		DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
 
@@ -742,16 +755,17 @@ int intel_hdcp_check_link(struct intel_connector *connector)
 	enum port port = intel_dig_port->base.port;
 	int ret = 0;
 
-	if (!hdcp->shim)
-		return -ENOENT;
-
 	mutex_lock(&hdcp->mutex);
 
-	if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+	/* Check_link valid only when HDCP1.4 is enabled */
+	if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
+	    !hdcp->hdcp_encrypted) {
+		ret = -EINVAL;
 		goto out;
+	}
 
-	if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
-		DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+	if (WARN_ON(!intel_hdcp_in_use(connector))) {
+		DRM_ERROR("%s:%d HDCP link stopped encryption,%x\n",
 			  connector->base.name, connector->base.base.id,
 			  I915_READ(PORT_HDCP_STATUS(port)));
 		ret = -ENXIO;
@@ -792,18 +806,6 @@ int intel_hdcp_check_link(struct intel_connector *connector)
 	return ret;
 }
 
-static void intel_hdcp_check_work(struct work_struct *work)
-{
-	struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
-					       struct intel_hdcp,
-					       check_work);
-	struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
-
-	if (!intel_hdcp_check_link(connector))
-		schedule_delayed_work(&hdcp->check_work,
-				      DRM_HDCP_CHECK_PERIOD_MS);
-}

Why move the function?
This will be used as common work fn for both 1.4 and 2.2. hdcp2_check_link will be defined below.
So moving this to the group of common functions. Basically to avoid the function declarations.

      

        
-
 static void intel_hdcp_prop_work(struct work_struct *work)
 {
 	struct intel_hdcp *hdcp = container_of(work, struct intel_hdcp,
@@ -1028,6 +1030,25 @@ int hdcp2_deauthenticate_port(struct intel_connector *connector)
 	return hdcp2_close_mei_session(connector);
 }
 
+static inline void _intel_hdcp_check_work(struct intel_connector *connector)
+{
+	struct intel_hdcp *hdcp = &connector->hdcp;
+
+	if (!intel_hdcp_check_link(connector))
+		schedule_delayed_work(&hdcp->check_work,
+				      DRM_HDCP_CHECK_PERIOD_MS);
+}
+
+static void intel_hdcp_check_work(struct work_struct *work)
+{
+	struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
+					       struct intel_hdcp,
+					       check_work);
+	struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+
+	_intel_hdcp_check_work(connector);
+}
+
 static int i915_hdcp_component_match(struct device *dev, void *data)
 {
 	return !strcmp(dev->driver->name, "mei_hdcp");
@@ -1156,7 +1177,8 @@ int intel_hdcp_disable(struct intel_connector *connector)
 
 	if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
 		hdcp->value = DRM_MODE_CONTENT_PROTECTION_UNDESIRED;
-		ret = _intel_hdcp_disable(connector);
+		if (hdcp->hdcp_encrypted)
+			ret = _intel_hdcp_disable(connector);
 	}
 
 	mutex_unlock(&hdcp->mutex);
@@ -1196,3 +1218,30 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
 						   new_state->crtc);
 	crtc_state->mode_changed = true;
 }
+
+/* Handles the CP_IRQ raised from the DP HDCP sink */
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector)
+{
+	struct intel_hdcp *hdcp = &connector->hdcp;
+
+	if (!hdcp->shim)
+		return;
+
+	/*
+	 * As of now we want to handle CP_IRQ triggered while encryption is
+	 * enabled. This includes the notification for Topology change,
+	 * Link failure, reauth request etc.
+	 * Auth msg availability notifications are ignored with mutex_trylock
+	 * as authentication holds the lock. Lock might be taken for link check
+	 * or hdcp_disable too. In either of state we need not handle the
+	 * CP_IRQ, for known reasons.
+	 */
+	if (!mutex_trylock(&hdcp->mutex))


      

      
This is not a good way to fix recursions, because the lock might be held
by someone else for other reasons, and then you just drop events on the
floor. Worse, usually it works, except when it stops working.

    

    
This is attempt to drop the CP_IRQ received during mutex is
      locked. Because of the below reasoning:

    

    
This mutex is taken by authentication enable/disable and
      check_link worker

    
when enable is in process this CP_IRQ will be notifying the msg availability to read. at present we dont use the CP_IRQ for msg read.
when disable is in process it doesn't matter why this CP_IRQ is triggered, we just want to ignore.

When check_link is in progress, that means hdcp is enabled. So this CP_IRQ is for topology change/reauth request etc,
which are handled by check_link. so once again we dont care for this CP_IRQs too.

So basically if the mutex is already taken we can ignore/drop the CP_IRQ. So mutex_trylock helps us to do this.
May be I should add all of these in the comment!?

While rethinking on that we can reschedule the check_link work on every CP_IRQ. As this is harmless i will do that. Makes things simple.


    

      

Since you already have a separate worker just schedule that one, and leave
it up to the worker to filter out events we don't care about.


    

    

      

        
+		return;
+
+	if (!hdcp->hdcp_encrypted)
+		return;


      

      
This check would need to be moved intel_hdcp_check_link().

    

    
Function has the check already. I can avoid the check here and
      directly land into check_link work fn.

    
-Ram

    

    

      

      

        
+
+	mutex_unlock(&hdcp->mutex);
+	_intel_hdcp_check_work(connector);


      

      
So instead of the direct call we need a schedule_work() here (without
delay ofc). Note that if the work is already scheduled it won't be
scheduled to run twice, so should just work as-is I think.

    

    

      
-Daniel


      

        
+}
-- 
2.7.4



      

      

    

  


--------------6FCFCFED2CFD10DF532848D7--

--===============1847221184==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4
IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg==

--===============1847221184==--